[E-devel] [Fwd: Re: License of your contribution to SMALL/PAWN]
The attached mail by Greg Garner did no reach the mailing list because the address was only in CC (not To). --- Begin Message --- --- End Message --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore IMF support for python-ecore
Hi list, I've coded a initial support for ecore-imf in python-ecore. In this first moment we have only the basic listing functions: ecore_imf_shutdown() ecore_imf_context_available_ids_get() ecore_imf_context_available_ids_by_canvas_type_get() ecore_imf_context_default_id_get() ecore_imf_context_default_id_by_canvas_type_get() ecore_imf_context_info_by_id_get() The ecore_imf_init() function will be called automatically when you import ecore.imf module, so it was necessary to make it public. The plan is to add full support for creating input method contexts in python incrementally. I'd like to ask the python and IMF gurus to please review the code in my python-ecore tree at staff.get-e.org: http://staff.get-e.org/?p=users/etrunko/python-ecore;a=summary Best Regards, Etrunko. -- Eduardo de Barros Lima INdT - Instituto Nokia de Tecnologia [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Systray - Ideas for a new spec
Im trying to get some chatter about a new systray spec on the freedesktop.org mailing list. Since Im no programmer myself, I would like to try to just solidify some points that you all have and then put them all together and mail it into them. I figure the problem wont fix itself and some of you have some good ideas for it. Lets make some noise about this while KDE4 is fresh and see if any collaboration in that respect can happen. Toma - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-03-04 07:09:02 -0800
Build log for Enlightenment DR 0.17 on 2008-03-04 07:09:02 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log edje_editor http://download.enlightenment.org/tests/logs/edje_editor.log edvi http://download.enlightenment.org/tests/logs/edvi.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, e_dbus, edje, edje_viewer, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] new release of my wallpaper fetcher
Could you test this set of patch ?
On Mon, Mar 3, 2008 at 7:11 PM, Massimiliano Calamelli
<[EMAIL PROTECTED]> wrote:
> I'll be very happy to help you for tests.
>
> massimiliano
--
Cedric BAIL
From c3ddd94569aed2dd8c5cc5a7b14d56f1ab2e913f Mon Sep 17 00:00:00 2001
From: Cedric BAIL <[EMAIL PROTECTED]>
Date: Thu, 28 Feb 2008 16:07:38 +0100
Subject: [PATCH] Add a way to directly store the result of a ecore_con_url request inside a fd.
---
src/lib/ecore_con/Ecore_Con.h |2 +
src/lib/ecore_con/ecore_con_private.h |3 +
src/lib/ecore_con/ecore_con_url.c | 87 ---
src/lib/ecore_download/ecore_download.c | 48 +
4 files changed, 98 insertions(+), 42 deletions(-)
diff --git a/src/lib/ecore_con/Ecore_Con.h b/src/lib/ecore_con/Ecore_Con.h
index 01375f4..a23e365 100644
--- a/src/lib/ecore_con/Ecore_Con.h
+++ b/src/lib/ecore_con/Ecore_Con.h
@@ -196,6 +196,8 @@ extern "C" {
EAPI void ecore_con_url_data_set(Ecore_Con_Url *url_con, void *data);
EAPI void *ecore_con_url_data_get(Ecore_Con_Url *url_con);
EAPI int ecore_con_url_url_set(Ecore_Con_Url *url_con, const char *url);
+ EAPI void ecore_con_url_fd_set(Ecore_Con_Url *url_con, int fd);
+ EAPI int ecore_con_url_received_bytes_get(Ecore_Con_Url *url_con);
EAPI int ecore_con_url_send(Ecore_Con_Url *url_con, void *data, size_t length, char *content_type);
EAPI void ecore_con_url_time(Ecore_Con_Url *url_con, Ecore_Con_Url_Time condition, time_t tm);
diff --git a/src/lib/ecore_con/ecore_con_private.h b/src/lib/ecore_con/ecore_con_private.h
index 820771a..ae0332a 100644
--- a/src/lib/ecore_con/ecore_con_private.h
+++ b/src/lib/ecore_con/ecore_con_private.h
@@ -79,6 +79,9 @@ struct _Ecore_Con_Url
Ecore_Fd_Handler *fd_handler;
+ int received;
+ int fd;
+
unsigned char active : 1;
};
#endif
diff --git a/src/lib/ecore_con/ecore_con_url.c b/src/lib/ecore_con/ecore_con_url.c
index d114a0d..be46b94 100644
--- a/src/lib/ecore_con/ecore_con_url.c
+++ b/src/lib/ecore_con/ecore_con_url.c
@@ -40,6 +40,8 @@
#include "Ecore_Con.h"
#include "ecore_con_private.h"
+#include
+
/**
* @defgroup Ecore_Con_Url_Group Ecore URL Connection Functions
*
@@ -230,6 +232,8 @@ ecore_con_url_new(const char *url)
curl_easy_setopt(url_con->curl_easy, CURLOPT_TIMEOUT, 300);
curl_easy_setopt(url_con->curl_easy, CURLOPT_FOLLOWLOCATION, 1);
+ url_con->fd = -1;
+
return url_con;
#else
return NULL;
@@ -376,6 +380,40 @@ ecore_con_url_time(Ecore_Con_Url *url_con, Ecore_Con_Url_Time condition, time_t
* @return FIXME: To be documented.
* @ingroup Ecore_Con_Url_Group
*/
+EAPI void
+ecore_con_url_fd_set(Ecore_Con_Url *url_con, int fd)
+{
+ if (!ECORE_MAGIC_CHECK(url_con, ECORE_MAGIC_CON_URL))
+ {
+ ECORE_MAGIC_FAIL(url_con, ECORE_MAGIC_CON_URL, "ecore_con_url_set");
+ return ;
+ }
+
+ url_con->fd = fd;
+}
+
+/**
+ * FIXME: To be documented.
+ * @return FIXME: To be documented.
+ * @ingroup Ecore_Con_Url_Group
+ */
+EAPI int
+ecore_con_url_received_bytes_get(Ecore_Con_Url *url_con)
+{
+ if (!ECORE_MAGIC_CHECK(url_con, ECORE_MAGIC_CON_URL))
+ {
+ ECORE_MAGIC_FAIL(url_con, ECORE_MAGIC_CON_URL, "ecore_con_url_received_bytes_get");
+ return -1;
+ }
+
+ return url_con->received;
+}
+
+/**
+ * FIXME: To be documented.
+ * @return FIXME: To be documented.
+ * @ingroup Ecore_Con_Url_Group
+ */
EAPI int
ecore_con_url_send(Ecore_Con_Url *url_con, void *data, size_t length, char *content_type)
{
@@ -448,15 +486,50 @@ _ecore_con_url_data_cb(void *buffer, size_t size, size_t nmemb, void *userp)
size_t real_size = size * nmemb;
url_con = (Ecore_Con_Url *)userp;
- e = malloc(sizeof(Ecore_Con_Event_Url_Data) + sizeof(unsigned char) * (real_size - 1));
- if (e)
+
+ if (!url_con) return -1;
+ if (!ECORE_MAGIC_CHECK(url_con, ECORE_MAGIC_CON_URL))
{
- e->url_con = url_con;
- e->size = real_size;
- memcpy(e->data, buffer, real_size);
- ecore_event_add(ECORE_CON_EVENT_URL_DATA, e,
- _ecore_con_event_url_free, NULL);
+ ECORE_MAGIC_FAIL(url_con, ECORE_MAGIC_CON_URL, "ecore_con_url_destroy");
+ return -1;
}
+
+ url_con->received += real_size;
+
+ if (url_con->fd < 0)
+ {
+ e = malloc(sizeof(Ecore_Con_Event_Url_Data) + sizeof(unsigned char) * (real_size - 1));
+ if (e)
+ {
+ e->url_con = url_con;
+ e->size = real_size;
+ memcpy(e->data, buffer, real_size);
+ ecore_event_add(ECORE_CON_EVENT_URL_DATA, e,
+ _ecore_con_event_url_free, NULL);
+ }
+ }
+ else
+ {
+ ssize_t count = 0;
+ size_t total_size = real_size;
+ size_t offset = 0;
+
+ while (total_size > 0)
+ {
+ count = write(url_con->fd, (char*) buffer + offset, total_size);
+ if (count < 0)
+ {
+ if (errno != EAGAIN && errno != EINTR)
+ return -1;
+ }
+ else
+ {
+ total_size -= count;
+
Re: [E-devel] [PATCH] Eet file format change
On Mon, 3 Mar 2008 15:54:25 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
decompile isnt broken more than it was :) but still. got a test case for you:
eet -d sample.edj edje_file out.txt
this should work and produce a text file dump of the contents much like
blah "" {
blah "
...
}
in out.txt
:)
> On Sun, Mar 2, 2008 at 6:50 AM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> > On Sun, 2 Mar 2008 02:43:48 -0300 "Gustavo Sverzut Barbieri"
> > <[EMAIL PROTECTED]> babbled:
> > > On Sun, Mar 2, 2008 at 12:48 AM, The Rasterman Carsten Haitzler
> > > <[EMAIL PROTECTED]> wrote:
> > > > On Fri, 15 Feb 2008 15:56:12 +0100 "Cedric BAIL" <[EMAIL PROTECTED]>
> > > > babbled:
> > > >
> > > > i found a wonderful nasty "bug"...
> > > >
> > > > 1. edje keeps the eet handle open.
> > > > 2. edje uses the string dictionary
> > > > 3. what happens if you delete the edj file edje is depending on and
> > > > it then tries to make use of any o the strings from the
> > > > dictionary... :) (hint: some signal around #11 :)).
> > > >
> > > > :)
> > > >
> > > > try this. use some theme X in e. have the source and recompile it (be
> > > > nice
> > > > - delete the original. recompiling the theme in-place is even worse as
> > > > u screw with the file that eet has mmaped() in with string dictionary
> > > > data):
> > > >
> > > > rm X.edj; edje_cc X.edc
> > > >
> > > > now go move your mouse around. move a window. bam. segv. :)
> > >
> > > this is the same thing for running binaries, but since it's a common
> > > case you get an error and the binary can't be removed with a "file
> > > busy". There is a correct procedure for doing such things that takes
> > > reference counting from FS to make it behave. I don't have time to
> > > search for it now, will do it tomorrow when I wake up.
> >
> > actualyl the bug was a refcount issue - it was literally deleting the eet
> > handle before its time - its refcount got to 0 when it shouldnt have. thus
> > the file descriptor was closed and thus we lost the dictionary contents. if
> > we retained the file handle and the mmap we are fine as long as u delete the
> > old .edj first then replace it as unix fs semantics will keep the open
> > copy. of course win32 will break wonderfully :).
>
> Just attached a patch that will do the job for the moment. For now,
> it's just doing a strdup of each string, so they are safe when you use
> it (their is still some possibility for a race condition as it is
> possible to change the file between eet_open and eet_data_read). I
> don't know if it would be a good idea to malloc and memcpy all the
> dictionary, but at the end all string will be copied in memory anyway.
> So it's perhaps the fix for Windows.
>
> > and yes - replacing the .edj in-place is dangerous and will cause problems
> > like this or even segv's now. before it was safe. i fixed this now, but we
> > have other problems :) compression no longer works for eet data encoded
> > sections as the eet data is decoded with pointers TO the data chunk it was
> > decoded from, but if compressed this is freed as the data one decoded is
> > expected t be stand-alone and not dependent on the original data lump it
> > was decoded from.
>
> It was missing some code arount EET_T_INLINED_STRING, should work
> cleanly now with compression enable and the second patch.
>
> --
> Cedric BAIL
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] new release of my wallpaper fetcher
Sure, but tomorrow, this evening i'm very busy. To do double checks, can you try my patch? It uses a lot ecore_file_download, around 16 simultaneous for static wp, and 34 for animated. massimiliano 2008/3/4, Cedric BAIL <[EMAIL PROTECTED]>: > Could you test this set of patch ? > > On Mon, Mar 3, 2008 at 7:11 PM, Massimiliano Calamelli > <[EMAIL PROTECTED]> wrote: > > I'll be very happy to help you for tests. > > > > massimiliano > > -- > Cedric BAIL > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore IMF support for python-ecore
On Tue, Mar 4, 2008 at 11:19 AM, Eduardo Lima (Etrunko) <[EMAIL PROTECTED]> wrote: > Hi list, > > I've coded a initial support for ecore-imf in python-ecore. In this > first moment we have only the basic listing functions: > > ecore_imf_shutdown() > ecore_imf_context_available_ids_get() > ecore_imf_context_available_ids_by_canvas_type_get() > ecore_imf_context_default_id_get() > ecore_imf_context_default_id_by_canvas_type_get() > ecore_imf_context_info_by_id_get() > > The ecore_imf_init() function will be called automatically when you > import ecore.imf module, so it was necessary to make it public. The > plan is to add full support for creating input method contexts in > python incrementally. > > I'd like to ask the python and IMF gurus to please review the code in > my python-ecore tree at staff.get-e.org: > > http://staff.get-e.org/?p=users/etrunko/python-ecore;a=summary in cvs. -- Gustavo Sverzut Barbieri http://profusion.mobi - Embedded and Mobile Software Development -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore IMF support for python-ecore
On Tue, Mar 4, 2008 at 5:14 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > in cvs. w00t! -- Eduardo de Barros Lima INdT - Instituto Nokia de Tecnologia [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] i18n for the configure title
Hi,
attached is a small patch to make the string "Enlightenment Configure"
translatable for translator.
Index: data/themes/default_configure.edc
===
RCS file: /cvs/e/e17/apps/e/data/themes/default_configure.edc,v
retrieving revision 1.23
diff -u -r1.23 default_configure.edc
--- data/themes/default_configure.edc 17 Sep 2007 12:03:47 - 1.23
+++ data/themes/default_configure.edc 5 Mar 2008 01:21:49 -
@@ -66,7 +66,7 @@
}
}
part {
- name: "title";
+ name: "e.text.title";
type: TEXT;
effect:SOFT_SHADOW;
mouse_events: 0;
@@ -88,7 +88,7 @@
color3: 0 0 0 32;
color_class: "configure_title";
text {
- text: "Enlightenment Configuration";
+ text: "EC";
font: "Sans:style=Bold,Edje-Vera-Bold";
size: 16;
min: 1 1;
Index: src/modules/conf/e_conf.c
===
RCS file: /cvs/e/e17/apps/e/src/modules/conf/e_conf.c,v
retrieving revision 1.11
diff -u -r1.11 e_conf.c
--- src/modules/conf/e_conf.c 23 Jan 2008 09:04:55 - 1.11
+++ src/modules/conf/e_conf.c 5 Mar 2008 01:21:49 -
@@ -129,6 +129,8 @@
eco->edje = edje_object_add(eco->evas);
e_theme_edje_object_set(eco->edje, "base/theme/configure",
"e/widgets/configure/main");
+ edje_object_part_text_set(eco->edje, "e.text.title",
+ _("Enlightenment Configuration"));
eco->o_list = e_widget_list_add(eco->evas, 1, 1);
edje_object_part_swallow(eco->edje, "e.swallow.content", eco->o_list);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Sticky windows
On Sun, 24 Feb 2008 20:35:13 +0100 Peter van de Werken <[EMAIL PROTECTED]> babbled: > Got a couple of patches related to sticky windows: > > stickysignal.e17.diff > Add edje signals to e17 for window sticky state changes, and also > allow the border/theme to toggle the sticky state of a window. thats cool. one thing with the above patch - you patch e_config.c and e_border.c bu the same patch refers to the 2 different files with different paths so it can never apply cleanly. next time make sure the diff is consistent :) > stickywindows.e17.ibox.diff > With the ibox module set to only show the windows of the active > desktop, it now also shows the sticky windows from the other desktops. > > maximise.e17.diff > When using the 'Fill available space' maximize policy, a maximising > window now takes also takes into account all the sticky windows (not > just the ones on the active desktop). And it also now ignores windows > that are iconified. > > regards, > Peter van de Werken > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] DirectFB, Intel GDL, Overlays and more
On Sun, 24 Feb 2008 22:41:59 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: i can't answer with respect to directfb, but the hardware you have is probably similar to what i've seen before. you get multiple display layers/planes (multiple framebuffers). one layer is YUV video data - thats your video layer. you are expected to just decode all video data into here and the hardware will convert to RGB and scale. it's really only mostly useful for 1 video at a time, and is "intended" to be fullscreen (you can twist it to do more, but only for limited uses). you may get a second YUV video layer for picture-in-picture, but then you get an overlay layer thats RGBG of some sort. maybe 32bit ARGB or 16bit RGB656 + an alpha mask or rgb555 with 1 bit for alpha (on/off) or maybe even color-keyed. this layer is probably where you want to render stuff into with evas most likely. now the question comes - how much help does the hardware supply in rendering to this layer? in my experience it generally is very minimal or even non-existent. you need to check what drawing operations are supported and what their limitations are. i might be tempted to do an engine just for GDL to draw in the overlay layer with evas (and leave video to something else). DFB is your other choice there. > Hi guys, > > I'll have to work with an Intel consumer electronics soon (CE2110, > [1]) so I started to investigate its capabilities and found that it > provides video overlays optimized for media playbacks, so you can > provide nice OSD (on screen display) without wasting much CPU, also > this board have some hardware decoders for h264 and mpeg2 and I guess > these do output to these overlays. > > They provide video drivers with their own library called GDL - > Graphics Device Library [2], with backend/engines for SDL and > DirectFB. This GDL seems to be pretty decent in hardware support, with > 2D including primitives like line, rectangle and blits (alpha, scaled > too [3]). This library itself is a tiny convenience library to issue > ioctl() to their kernel driver. > > I could not find CE2110 SDK, but there is one for the 854 chipset [4] > that contains sample programs with the GDL, just download it, > uncompress 8xxpsp-GDL-1.1-135.i386.rpm and then see > ./usr/local/gdl-8xx/samples/ > > Now to Evas part: we have an outdated DirectFB which AFAIK nobody is > using or willing to maintain and we (more specifically Cedric) have > SDL almost integrated. >I know SDL is really bare bones, so overhead of it should be > minimum, however due it being bare bones I fear it not exposing > primitives we could benefit. I couldn't find any source code or patch > for SDL, so I'm not sure what they optimized. >I don't know DirectFB more than reading their website some years > ago, but looking at their code and the patch provided by Intel, looks > like they do optimize some things. They have a README.txt with: > """ > """ 3. Current supported GDL accelerated features of DirectFB > """1) Overlay surface source color key is supported.. > """2) Below drawing functions are accelerated via GDL for all > video system surfaces: > """draw lines; > """draw rectangles, fill rectangles, fill triangle with single color; > """strecth blt with alpha blending and alpha scaler. > """ > > So I'm not sure on how to proceed. Would it be better to get DirectFB > in shape, use SDL or write Evas GDL engine? Maybe my requirements can > help somehow: > - basic usage will be a digital tv set top box, so it's full high > definition video with eventually some nice OSD on top of it. > - it would be great to have semi-transparent OSD. > - CPU is ARM/Xscale at 1Ghz, so fancy on-cpu graphics may not be > possible (ie: emotion). > - future will require me to run more things than just my > application, maybe having Firefox and some other programs. This may be > a good point for DirectFB? (I don't know if they compiled with the > multi-app support, but given they provide a patch, it may be possible > to recompile with this support). > > If you have any knowledge of this topic, please help. I'm still a bit > confused about this overlay thing, maybe it's very helpful, as if you > can have a ARGB overlay with my GUI so I port Evas to it, run it as > ARGB surface and play the video on the background from another place. > But maybe it's not like that and it's just a way to get hardware to > output to some region directly (like h264/mpeg2 decoders writing to > it) and I'd have to draw my surface on top of it using colorkey or > retrieving the pixels (possible slow) to do alpha blend, making things > more difficult. > > What's the state of DirectFB? Was it running fine one day (ie: > directfb part is okay, it just lag behind Evas api changes)? > > > > [1] http://www.intel.com/design/celect/2110/index.htm > [2] http://www.intel.com/design/celect/2110/tools.htm > [3] gdl_int32 gdl_blt(gdl_context_t* context, gdl_uint32 > src_surfac
Re: [E-devel] Feature Request: Separate submenu backgrounds
On Mon, 25 Feb 2008 13:04:34 +0900 Toma <[EMAIL PROTECTED]> babbled: > After doing a bit of design with this new grunge theme and wanting a > little skull in the menu, I found that its impossible to set a > separate submenu background and as such, have the skull on every menu. > Its a little too much for everywhere. Id like to see it possible to > have a separate background for it. > Im aware of name: "e/widgets/menu/default/submenu_bg" but that only > sets the background for the actual submenu item. > If no-one bothers, I might try copy and pasting some code and seeing > if I can get it to work, but I really cant code. Only EDJE and GIMP :D > Thanks, > Toma- this is part of a more general limitation - i know we should be able to have different menu design per menu (toplevel then sub, then sub-sub and sub-sub-sub etc.) as well as different ones for specific menus (start menu different to popup menu over some gadget for example). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Edje improvement
On Mon, 25 Feb 2008 15:28:59 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > > > > There are a couple of other smart class functions that would > > > also be useful with smart objects, in particular min/max_size_get > > > functions, and add similar functions to the evas api so that one > > > can query an evas object's min/max size. > > > > I already though about that, and perhaps a way to only specify one > > direction could be usefull. If you want to setup a textblock, you > > know the width but not the height you want. Or for an image object > > this could give you a way to have without special case in your code > > a way to respect aspect ratio. Not that this is difficult or > > impossible to code today, just easier if the object told us the > > right answer. > > Also, consider when one has an edje group that swallows an > external object. When calculating the edje's min/max size, you need > to know the swallowed part's such.. Well, right now, this is done > in edje in a very ad-hoc way and can be problematic to deal with in > general for swallowed objects that are designed to have min/max > sizes (but aren't edjes themselves). well you attach the data - but yes. evas itself should get these as they would be very useful. even getting callbacks like size_request for example, so a parent or another object can ask for a requested size and the child (or parent) can reply with the size it is able to do that is closest. > > > I should add though that in this particular case, there could > > > be potential 'side effects' in event handling.. because, some > > > changes of state that could be affecting the size and positioning > > > of things, would then be deferred to render_pre time, and hence > > > possibly not be detected by the events system. It's something > > > you'd have to investigate as to what consequences it might have, > > > in this particular case. > > > > I may be wrong, but I don't see a reason for edje_calc to send > > signal right now, nor did I saw a direct to it from edje_calc. > > Perhaps someone with more knowledge on edje could give a better > > view of the problem. > > Sometime ago, I considered doing this very same thing with > edje_calc. Never did get around to looking into that in more detail, > but I dimly recall there was some issue on my mind that was related > to this consideration. It's been a long time now and I can't recall > exactly why.. but just thought I'd mentioned it to you. it will break some things. we can add a calc_force call for these situations and find them and fix them :) > _ > Click here to obtain free information on accredited degrees. > http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l8OpuBKdPwAvyspcKtyTT47qT3nL2bhKiFPwnkjkdHxiapC/ > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Webkit
On Mon, 25 Feb 2008 23:50:41 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > On Mon, Feb 25, 2008 at 9:09 PM, raoul <[EMAIL PROTECTED]> wrote: > > Hi there, > > > > I think there is a great stuff missing in efls, it's a web rendering > > engine. The main purpose would be to have a full-efl based web browser. But > > also have some web rendering inside Evas/Edje based apps. This could really > > be awsome. > > > > I started to search how to have such capability and there are not many > > options. The first one could be to write our own, from scratch. This would > > probably be a huge task to do. I don't think it's the way. > > > > The second idea is to use Webkit as the web engine. It seems to be a good > > engine with great performance, compatibility and standards compliance. > > My idea would be to write an Evas smart object which will do the rendering > > stuff using webkit and expose some nice functions to the user like > > load_url(), reload_page(), ... > > The rendering process will use Evas. I check a little the webkit code, ans > > it seems like it could be done. Perhaps some rendering part would need some > > Evas modifications, I don't know yet. But it should not be impossible to do. > > > > Having all of that right into a new library (e_web?) could reallly be a > > great improvement to Efl's power. > > Eh, you're not the first one to notice it :-) > > INdT is working on such a library. Albeit I did the initial "route > planing" I couldn't keep a closer eye on it due heavy work on Canola2, > but I think they have some progress on that. I'll try to ask what's > the project status so far and possible a snapshot. > > As for implementation details, smart object is not the best option, > actually using Evas as WebKit backend is not the best option around. > Why? The major problem is that webkit is state-less, while evas is > state-full. Also webkit requires just few primitives in order to > render, you just have to implement the advanced primitives if you want > SVG loader and Canvas support, other than that it just render simple > (continuous, same font, effect, size...) text at some given position, > rectangles and images... It does the layout, line breaking, ... > So the best option is to draw to some buffer and use this as image > data, then take care of event passing to this webkit engine. Using > this solution have one major drawback: if you have some animation, it > would require 2 blits instead of one (one to buffer, then from buffer > to screen), but this allow you to play with primitives as scale, color > modulation (fade out, colorize, ) and clip some regions. yeah - thats probably the best way to do it. the other way would be as an actual extension to evas and as a core object in evas. this would make evas dependent on webkit what would be the right way would be to allow new extended objects (smart objects) to set rendering calls - the same way evas internal objects do, and then do their own rendering. breaking this out to a nice public api would be really nice and allow for objects built on a non-stateful (immediate mode) rendering model to exist and be efficient without HAVING to render to a buffer. this would mean breaking out the engine drawing calls and surface creation/destruction etc. into evas api. after that u can more easily implement a webkit object that draws natively really nicely and in theory could use hardware accel to do it with gl, xrender etc. engines. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje Edit patch ready
On Tue, 26 Feb 2008 13:28:14 +0100 Dave <[EMAIL PROTECTED]> babbled: as this is so cool a thing, i'm putting your patch into edje code - so any more work for edje_edit - put it there :) we'll work in mainline. good work mate! good work! > Gustavo Sverzut Barbieri ha scritto: > > On Mon, Feb 25, 2008 at 11:11 PM, Dave <[EMAIL PROTECTED]> wrote: > > > >> Hi list ! > >> As you can see I have worked hard to the editor and to the edje patch in > >> the last weeks... > >> Now I think that the patch is ready to be committed, and maybe the > >> editor can be moved out of proto :) > >> > >> The editor now is really complete, no more 'not yet implemented msg' > >> around and no more 'big' things to do. > >> You should really give it a try now, it can spread the power of edje. > >> > > > > > > That's great to see! Congrats! > > > > I still have to test it, but I guess it's ok. Will try to find some > > time to do it next weekend. > > > > > > > > > >> A little explanation of the edje patch: > >> As you can probably know the patch don't touch any edje code (so that > >> the edje stability and performance are ok), > >> I have add 2 big files to edje (edje_edit.c and Edje_Edit.h). All my > >> work is inside and all the lib is doxy-commented. > >> Outside of this 2 files I have only made some 'char*' to 'const char *' > >> and removed a 'static' from a function that I need. > >> > > > > If it's harmless, then let's try :-) > > > > > > > >> some little more information in the wiki: > >> http://wiki.enlightenment.org/index.php/Edje_Editor > >> > > > > There I see you don't support decompiling, is that because you don't > > provide the text source in the eet? I don't know how you do the > > serialization of in-memory structs, but shouldn't be too hard, am I > > wrong? > > > > > Yes, not difficult, I'm working on this now, just have to printout well > all the structs back to the edje. > There are no more difficult think to do :) > > Thanks again, > > > > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore_timer_freeze and ecore_timer_thaw
On Wed, 27 Feb 2008 14:16:10 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled: > This patch give the possibilite to suspend the execution of a timer > for as long as you want. Freezing a timer, remove it from the main > active timer list and push it on the suspended list waiting to be > thaw. The code is fairly simple, and remove the need to handle this in > the application. looks like it should work and not break... except your patch doesnt include changes to ecore_private.h too - like adding pending and frozen members to the timer struct :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] start module
On Fri, 29 Feb 2008 11:59:02 +0100 Peter van de Werken <[EMAIL PROTECTED]> babbled: > A small patch for the start module: instead of hardcoding the size of the > shell icon/button, get it from the theme. in cvs :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH 1/5] Add comments for dbus peer functions.
On Sat, 1 Mar 2008 22:46:27 +0100 Stefan Schmidt <[EMAIL PROTECTED]> babbled: hey stefan... can you send the patches attached to a mail - not inlined? mailers like to linewrap and such. by sending as attachments you'll make sure that we get the patches exactly as you generated them whitespace for whitespace :) > Hello. > > This is the first patch with some small fixes for e_nm and stuff I > found on my way working on it. > > Nothing really nice yet, but I like to get the patchset down instead > of posting all at once and nobody like to review such a big set. > > From my understanding e_nm was started, but not used in any > application yet. The overall structur is good, but sadly the NM dbus > API changed completely. Former they used function calls with parameter > and return values only. Now they use a lot properties on the > interfaces and added more interfaces. I would like to keep this easy > and just use structs filled with the given properties. See last patch. > > The latest example code, e_dbus_nm, does not run at all with newer svn > version of NM 0.7 because of all the API changes. So I see two ways of > handle the transition: > > 1) I completely kick all non-working functions in one shot and start > from the still working stuff. > > 2) I replace non-working by working function for function. > > Let me know your comments about code and ideas. > > regards > Stefan Schmidt > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E CVS: apps/e raster
Hey raster, is it possible you've lost two files,
e_int_config_wallpaper .c and .h? There's no reference in cvs commit
massimiliano
-- Forwarded message --
From: Enlightenment CVS <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 00:35:37 -0500 (EST)
Subject: E CVS: apps/e raster
To: [EMAIL PROTECTED]
Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Dir : e17/apps/e/src/modules/conf_wallpaper
Modified Files:
Makefile.am e_int_config_wallpaper.c e_mod_main.h
Log Message:
Massimiliano's rss feed wallpaper fetching and browsing stuff. really cool.
probably needs mroe work, but cool enough for mainline :)
===
RCS file: /cvs/e/e17/apps/e/src/modules/conf_wallpaper/Makefile.am,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- Makefile.am 4 Jul 2007 15:09:24 - 1.1
+++ Makefile.am 5 Mar 2008 05:35:37 - 1.2
@@ -25,7 +25,9 @@
e_int_config_wallpaper_gradient.h \
e_int_config_wallpaper.h \
e_int_config_wallpaper_import.c \
-e_int_config_wallpaper_import.h
+e_int_config_wallpaper_import.h \
+e_int_config_wallpaper_web.c \
+e_int_config_wallpaper_web.h
module_la_LIBADD = @e_libs@ @dlopen_libs@
module_la_LDFLAGS = -module -avoid-version
===
RCS file:
/cvs/e/e17/apps/e/src/modules/conf_wallpaper/e_int_config_wallpaper.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -3 -r1.8 -r1.9
--- e_int_config_wallpaper.c14 Dec 2007 16:34:47 - 1.8
+++ e_int_config_wallpaper.c5 Mar 2008 05:35:37 - 1.9
@@ -55,6 +55,7 @@
/* dialogs */
E_Win *win_import;
E_Dialog *dia_gradient;
+ E_Dialog *dia_web;
};
EAPI E_Config_Dialog *
@@ -151,6 +152,15 @@
cfdata->dia_gradient = NULL;
}
+EAPI void
+e_int_config_wallpaper_web_done(E_Config_Dialog *dia)
+{
+ E_Config_Dialog_Data *cfdata;
+
+ cfdata = dia->cfdata;
+ cfdata->dia_web = NULL;
+}
+
EAPI void
e_int_config_wallpaper_handler_set(Evas_Object *obj, const char
*path, void *data)
{
@@ -381,6 +391,18 @@
}
static void
+_cb_web(void *data1, void *data2)
+{
+ E_Config_Dialog_Data *cfdata;
+
+ cfdata = data1;
+ if (cfdata->dia_web)
+ e_win_raise(cfdata->dia_web->win);
+ else
+ cfdata->dia_web = e_int_config_wallpaper_web(cfdata->cfd);
+}
+
+static void
_fill_data(E_Config_Dialog_Data *cfdata)
{
char path[4096];
@@ -460,6 +482,8 @@
e_int_config_wallpaper_del(cfdata->win_import);
if (cfdata->dia_gradient)
e_int_config_wallpaper_gradient_del(cfdata->dia_gradient);
+ if (cfdata->dia_web)
+ e_int_config_wallpaper_web_del(cfdata->dia_web);
E_FREE(cfdata->bg);
E_FREE(cfd->data);
E_FREE(cfdata);
@@ -543,7 +567,7 @@
e_fm2_pan_max_get,
e_fm2_pan_child_size_get);
cfdata->o_frame = of;
- e_widget_min_size_set(of, 160, 160);
+ e_widget_min_size_set(of, 60, 60);//***
e_widget_table_object_append(ot, of, 0, 2, 1, 1, 1, 1, 1, 1);
e_widget_list_object_append(o, ot, 1, 1, 0.0);
@@ -558,6 +582,12 @@
ow = e_widget_button_add(evas, _("Gradient..."), "enlightenment/gradient",
_cb_gradient, cfdata, NULL);
e_widget_table_object_append(ot, ow, 1, 1, 1, 1, 1, 0, 0, 0);
+ if (ecore_file_download_protocol_available("http://";))
+ {
+ ow = e_widget_button_add(evas, _("Online..."), "enlightenment/website",
+ _cb_web, cfdata, NULL);
+ e_widget_table_object_append(ot, ow, 2, 1, 1, 1, 1, 0, 0, 0);
+ }
mw = 320;
mh = (320 * zone->h) / zone->w;
@@ -704,6 +734,12 @@
ow = e_widget_button_add(evas, _("Gradient..."), "enlightenment/gradient",
_cb_gradient, cfdata, NULL);
e_widget_table_object_append(ot, ow, 1, 1, 1, 1, 1, 0, 0, 0);
+ if (ecore_file_download_protocol_available("http://";))
+ {
+ ow = e_widget_button_add(evas, _("Online..."), "enlightenment/website",
+ _cb_web, cfdata, NULL);
+ e_widget_table_object_append(ot, ow, 2, 1, 1, 1, 1, 0, 0, 0);
+ }
mw = 320;
mh = (320 * zone->h) / zone->w;
===
RCS file: /cvs/e/e17/apps/e/src/modules/conf_wallpaper/e_mod_main.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -3 -r1.2 -r1.3
--- e_mod_main.h31 Oct 2007 12:23:12 - 1.2
+++ e_mod_main.h5 Mar 2008 05:35:37 - 1.3
@@ -8,10 +8,12 @@
#include "e_int_config_wallpaper.h"
#include "e_int_config_wallpaper_import.h"
#include "e_int_config_wallpaper_gradient.h"
+#include "e_int_config_wallpaper_web.h"
#undef E_TYPEDEFS
#inclu
Re: [E-devel] License of your contribution to SMALL/PAWN
On Tue, 4 Mar 2008 18:20:16 GMT [EMAIL PROTECTED] babbled: thanks! made so! :) > Jan: > > Sounds good to me, make it so! > > Greg Garner > > > On Mon, 03 Mar 2008 19:28:52 +0100 Jan Lübbe <[EMAIL PROTECTED]> babbled: > > > > as long as you are happy to have it have an identical license statement > as the > > rest of pawn/small(we call it embryo as we have made modifications that mean > > it's not 100% compatible with other amx bytecode, but simpler and a > little more > > efficient, thus the rename to avoid any confusion of compatibility), i > can just > > edit it for you (put the zlib license statement at he top - just put your > names > > in as per the existing header). > > > > > Hallo! > > > > > > You can see the file based on yours at: > > > > http://enlightenment.org/viewvc/e17/libs/embryo/src/lib/embryo_float.c?revision=1.1&view=markup > > > > > > > As this request relates mainly to the embryo package, i think the best > > > way is to ask the enlightenment developers to change your license > > > statement to the zLib license in their CVS. > > > > > > So just reply to this message (keeping > > > enlightenment-devel@lists.sourceforge.net in the recipient list) and > > > state explicitly that you want to relicense your work under the zLib > > > license. > > > > > > Thanks, Jan > > > > > > On Sun, 2008-03-02 at 01:26 +, [EMAIL PROTECTED] wrote: > > > > I am happy to change the license as you suggest, but I am not sure how > > > > to do this. Can you send me the file and I will edit it and then send it > back > > > > to you? > > > > > > > > Greg Garner > > > > www.rt-eng.com > > > > [EMAIL PROTECTED] > > > > +1-479-871-1148 Cell > > > > > > > > > Hello+ACE > > > > > > > > > > We are currently packaging embryo (a fork of SMALL/PAWN used by the > > > > > Enlighenment Desktop) for Debian and the archive maintainers have > > > > > noticed a small problem with the license statement of your > > > > > contribution to SMALL. > > > > > > > > > > According to http://www.compuphase.com/pawn/pawn.htm: > > > > > +ACI-Get a floating point extension module written by Greg Garner from > > > > > Real Time Engineering (1999-12-15) > > > > > The +ACI-pawn toolkit+ACI (see above) now also contains an expanded > > > > version of > > > > > this floating point module.+ACI > > > > > > > > > > The license statement in Float.cpp is: > > > > > /+ACo Float arithmetic for the Small AMX engine > > > > > +ACo > > > > > +ACo Copyright (c) Artran, Inc. 1999 > > > > > +ACo Written by Greg Garner (gmg+AEA-artran.com) > > > > > +ACo This file may be freely used. No warranties of any kind. > > > > > +ACo > > > > > +ACo-/ > > > > > > > > > > When interpreting this license strictly, only +ACo-use+ACo is allowed. > > > > Because > > > > > the default state in copyright law is forbidden, this file can't be > > > > > distributed, copied or modified. > > > > > > > > > > If this is simply a misunderstanding, we would appreciate it very much > > > > > if you could clarify your license statement. > > > > > > > > > > The easiest way to do this is to place your contribution under the > > > > > license used by SMALL/PAWN (the zLib license, > > > > > http://www.opensource.org/licenses/zlib-license.php) > > > > > > > > > > Regards, > > > > > Jan L+APw-bbe > > > > > > > > > > > > > > > > > - > > > > This message was sent using Endymion MailMan. > > > > http://www.endymion.com/products/mailman/ > > > > > > > > > > > > > - > > > This SF.net email is sponsored by: Microsoft > > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > > > > > - > This message was sent using Endymion MailMan. > http://www.endymion.com/products/mailman/ > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Wed, 5 Mar 2008 06:55:59 +0100 "Massimiliano Calamelli"
<[EMAIL PROTECTED]> babbled:
just in the middle of clearing out a lot of patches - was busy fixing up a min
size one and making it more consistent. done now. files added.
> Hey raster, is it possible you've lost two files,
> e_int_config_wallpaper .c and .h? There's no reference in cvs commit
>
> massimiliano
>
> -- Forwarded message --
> From: Enlightenment CVS <[EMAIL PROTECTED]>
> Date: Wed, 5 Mar 2008 00:35:37 -0500 (EST)
> Subject: E CVS: apps/e raster
> To: [EMAIL PROTECTED]
>
> Enlightenment CVS committal
>
> Author : raster
> Project : e17
> Module : apps/e
>
> Dir : e17/apps/e/src/modules/conf_wallpaper
>
>
> Modified Files:
> Makefile.am e_int_config_wallpaper.c e_mod_main.h
>
>
> Log Message:
>
>
> Massimiliano's rss feed wallpaper fetching and browsing stuff. really cool.
> probably needs mroe work, but cool enough for mainline :)
>
> ===
> RCS file: /cvs/e/e17/apps/e/src/modules/conf_wallpaper/Makefile.am,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -3 -r1.1 -r1.2
> --- Makefile.am 4 Jul 2007 15:09:24 - 1.1
> +++ Makefile.am 5 Mar 2008 05:35:37 - 1.2
> @@ -25,7 +25,9 @@
>e_int_config_wallpaper_gradient.h \
>e_int_config_wallpaper.h \
>e_int_config_wallpaper_import.c \
> - e_int_config_wallpaper_import.h
> + e_int_config_wallpaper_import.h \
> + e_int_config_wallpaper_web.c \
> + e_int_config_wallpaper_web.h
>
> module_la_LIBADD = @e_libs@ @dlopen_libs@
> module_la_LDFLAGS = -module -avoid-version
> ===
> RCS
> file: /cvs/e/e17/apps/e/src/modules/conf_wallpaper/e_int_config_wallpaper.c,v
> retrieving revision 1.8 retrieving revision 1.9
> diff -u -3 -r1.8 -r1.9
> --- e_int_config_wallpaper.c 14 Dec 2007 16:34:47 - 1.8
> +++ e_int_config_wallpaper.c 5 Mar 2008 05:35:37 - 1.9
> @@ -55,6 +55,7 @@
> /* dialogs */
> E_Win *win_import;
> E_Dialog *dia_gradient;
> + E_Dialog *dia_web;
> };
>
> EAPI E_Config_Dialog *
> @@ -151,6 +152,15 @@
> cfdata->dia_gradient = NULL;
> }
>
> +EAPI void
> +e_int_config_wallpaper_web_done(E_Config_Dialog *dia)
> +{
> + E_Config_Dialog_Data *cfdata;
> +
> + cfdata = dia->cfdata;
> + cfdata->dia_web = NULL;
> +}
> +
> EAPI void
> e_int_config_wallpaper_handler_set(Evas_Object *obj, const char
> *path, void *data)
> {
> @@ -381,6 +391,18 @@
> }
>
> static void
> +_cb_web(void *data1, void *data2)
> +{
> + E_Config_Dialog_Data *cfdata;
> +
> + cfdata = data1;
> + if (cfdata->dia_web)
> + e_win_raise(cfdata->dia_web->win);
> + else
> + cfdata->dia_web = e_int_config_wallpaper_web(cfdata->cfd);
> +}
> +
> +static void
> _fill_data(E_Config_Dialog_Data *cfdata)
> {
> char path[4096];
> @@ -460,6 +482,8 @@
> e_int_config_wallpaper_del(cfdata->win_import);
> if (cfdata->dia_gradient)
> e_int_config_wallpaper_gradient_del(cfdata->dia_gradient);
> + if (cfdata->dia_web)
> + e_int_config_wallpaper_web_del(cfdata->dia_web);
> E_FREE(cfdata->bg);
> E_FREE(cfd->data);
> E_FREE(cfdata);
> @@ -543,7 +567,7 @@
>e_fm2_pan_max_get,
>e_fm2_pan_child_size_get);
> cfdata->o_frame = of;
> - e_widget_min_size_set(of, 160, 160);
> + e_widget_min_size_set(of, 60, 60);//***
> e_widget_table_object_append(ot, of, 0, 2, 1, 1, 1, 1, 1, 1);
> e_widget_list_object_append(o, ot, 1, 1, 0.0);
>
> @@ -558,6 +582,12 @@
> ow = e_widget_button_add(evas, _("Gradient..."), "enlightenment/gradient",
> _cb_gradient, cfdata, NULL);
> e_widget_table_object_append(ot, ow, 1, 1, 1, 1, 1, 0, 0, 0);
> + if (ecore_file_download_protocol_available("http://";))
> + {
> + ow = e_widget_button_add(evas, _("Online..."), "enlightenment/website",
> +_cb_web, cfdata, NULL);
> + e_widget_table_object_append(ot, ow, 2, 1, 1, 1, 1, 0, 0, 0);
> + }
>
> mw = 320;
> mh = (320 * zone->h) / zone->w;
> @@ -704,6 +734,12 @@
> ow = e_widget_button_add(evas, _("Gradient..."), "enlightenment/gradient",
> _cb_gradient, cfdata, NULL);
> e_widget_table_object_append(ot, ow, 1, 1, 1, 1, 1, 0, 0, 0);
> + if (ecore_file_download_protocol_available("http://";))
> + {
> + ow = e_widget_button_add(evas, _("Online..."), "enlightenment/website",
> +_cb_web, cfdata, NULL);
> + e_widget_table_object_append(ot, ow, 2, 1, 1, 1, 1, 0, 0, 0);
> + }
>
> mw = 320;
> mh = (320 * zone->h) / zone->w;
> ==
Re: [E-devel] [PATCH] new release of my wallpaper fetcher
On Mon, 3 Mar 2008 18:25:10 +0100 Massimiliano Calamelli <[EMAIL PROTECTED]> babbled: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi devs, finally i'm ready to send the new release of my wallpaper > fetcher. As asked by raster i've done some changes, imho it works > fine, now. > Actually there's two online sources from get-e.org, one for static > background and one for animated. > I know that sometimes the module crashes when i close dialog after very > few time it start to download thumbs, but if you wait until the > end of downloads there's no problem. > If there's anyone that can help me about this issue... that's pretty cool. one problem is that you download everything first THEN put it in the dir. put each thumbnail into the dir AS each finishes. also no caching :( also the ui doesn't tell you it's busy outside of the titlebar so u get impatient :) i think this is cool enough to put into e now - so in it goes :) > Massimiliano > - -- > Massimiliano Calamelli > http://mcalamelli.netsons.org > [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > > iD8DBQFHzDR4leGEL56NNP4RAryPAKC0j2habM8PMpe6eZ86iupyWhL81gCaAwYT > u0OKc5e7m1YnR2mbjgxyGdg= > =efkx > -END PGP SIGNATURE- > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Systray - Ideas for a new spec
On Tue, 4 Mar 2008 23:59:44 +0900 Toma <[EMAIL PROTECTED]> babbled: > Im trying to get some chatter about a new systray spec on the > freedesktop.org mailing list. > Since Im no programmer myself, I would like to try to just solidify > some points that you all have and then put them all together and mail > it into them. > I figure the problem wont fix itself and some of you have some good > ideas for it. > Lets make some noise about this while KDE4 is fresh and see if any > collaboration in that respect can happen. > Toma well i've made them before on the wm spec list, so here goes: 1. systray "icon" windows are all implemented as solid windows. they are a hack around using icon windows in good old ICCCM but no better functionally - just much more obfuscated with all the selection mechanism stuff. as such they suffer the problems of icon windows: 1.1 can only have 1 copy of them on screen in 1 place. doesn't allow a tray to duplicate visual copies of them or functional ones. 1.2 they are windows - the implementations all assume that a tray will be in the same toolkit as the app (gtk just creates little grey box windows, kde/qt assume copyfromparent is a good idea for the background - which is a bad assumption). as such the spec discourages good implementation. 1.3 the spec should use the NETWM_ICON property to deliver an ARGB image to display. the tray can scale, draw, composite or whatever it wants. it can no create multiple copies. if the icon needs to change - a property change will do the job. doing more is probably abusing systray icons far beyond what they should be used for. 1.4 as such systray icons have just become a way for apps to avoid showing a main window but stay running. they function often simply as a replacement for iconification in icccm. thus using the same mechanism is the better way to go. 2. as such icons want some form of interaction with users - do be able to click on them to activate something or pop up a menu/dialog/popup of some sort. 2.1 we should implement a protocol via which an app can advertise some form of menu/popup structure to the systray so the systray can consistently implement menus on all systray icons in 1 style and 1 unified look. this falls in line with what is done in qtopia for the menu window (they use qcop to deliver this data) and with hildon on the n770/800/810 and the separated menu window. it would absorb this functionality as a unit on its own 2.2 in the case a systray cannot display what is needed being able to pass events (mouse motion, enter, leave, press and release events) as well as location of the tray icon relative to the root window. this way 1. the tray icons can be displayed with a consistent look irrespective of the toolkit or tray app, 2. can be placed in more than 1 location if desired, 3. can have a consistent look of any popup menus and controls and a consistent set of interaction, 3. will match more with the usage of the tray spec, 4. roll in other systems of abstracting this kind of "out of window control" element from other UI systems (qtopia, hildon). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
