Re: [E-devel] Evas/FB/ARM problem
On Tue, 20 Mar 2007 09:55:43 +0100 Massimiliano Calamelli <[EMAIL PROTECTED]> babbled: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, i've started to debug evas on my target device (ARM9) adding > some printf to the code, and i've seen a strange thing. > > Here a cut&paste from device console, i try to explain before the text this sounds strange - i'd need more analysis on this but it looks like you got stuck in recursion or a loop. the fb engine inherits from the software _generic one - thus the extra load of it - but software_generic doesn't inherit from anyone - so not sure whats up here. > /sbin # sb_evas1 > Evas inizializzato. > Evas canvas istanziato. > Engine disponibili: > fb > buffer > Framebuffer disponibile. > Output method: 1 > Step1 ! > evas_main.c : step 1. > evas_main.c : step 2. > em->type : 0. > EVAS_MODULE_TYPE_ENGINE: 0. > evas_main.c : step 3. > !em-data: 74024. > evas_main.c : step 4. > eme->id : 1, render_method: 1. > evas_main.c : step 5. > LOAD fb > path: /usr/lib/evas/modules/engines/fb/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/engines/software_generic/linux-gnu-arm/module.so. > LOAD software_generic > path: /usr/lib/evas/modules/en > ^C > /sbin # > > Explaining: > 0) Until "Step1 !" the messages are from my app; > 1) From "evas_main.c : step 1" to "evas_main.c : step 5" the messages > are from evas_main.c (evas/src/lib/canvas/evas_main.c) > 2) From "LOAD fb" to the end the messages are from evas_module.c > (evas/src/lib/file/evas_module.c) > 3) I've terminated my app sending ^C, you see the last line truncated, > if i wait i see a lot of "LOAD software_generic" and > "path: /usr/lib..", and the app crashes with segfault > > I'm not able to go into evas lib using gdbserver on target and gdb on > host, but it seems to be a strange loop, evas tries to use fb, it fails > (?) and switch to software_generic, and boom. > > LinuxFB runs fine, i've wrote a simple SDL app that runs, but my goal > is to use EFL! > > There's an Evas guru that it can help me? > > TIA > Massi > - -- > Massimiliano Calamelli > http://mcalamelli.netsons.org > [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.4 (MingW32) > > iD8DBQFF/6GPleGEL56NNP4RAtELAJ4/IG6rKqXjjUu5KH4g0MBHdqKodACgnUQp > 2RQ1pT+iYg7PtWPWPIjNeas= > =QbqI > -END PGP SIGNATURE- > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceFo
Re: [E-devel] Desklock's idle timer....
On Mon, 19 Mar 2007 00:50:26 -0500 Ravenlock <[EMAIL PROTECTED]> babbled: > Hello, > > The desklock's idle timer was apparently broken from the start. > Keyboard activity was not considered when determining if the user was > active or not. > > Here are some patches which fix this. With these patches a persons > keyboard and mouse activity are both taken into consideration when > determining if the user is active. > > This implementation requires that the XScreensaver extension be present. > This is the "easy" fix. If the powers that be prefer that this > functionality *not* depend on the XScreensaver extension, well... then > its a bigger problem. > > Questions/comments/complaints welcome. :) actually desklocks idle thing has always been broken. the e_manage though uses the xscreensaver events in _e_manager_cb_screensaver_notify() to turn on desklock if the screensaver kicks in :) > -- > Regards, > Ravenlock > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] TODO item(s) need clarification.....
On Fri, 16 Mar 2007 07:17:27 -0500 Ravenlock <[EMAIL PROTECTED]> babbled: > Hello, > > Can someone please elaborate on these items for me? > > * winlist could divide windows up into blocks - sub-lists within a > container per desktop (with stick windows considered to live on the > "current" desk when winlist starts) > > Is it just that someone wanted the windows grouped within the winlist > (similar to how the clientlist is now)? yes - currently winlist is just one big long list. being able to segment it per desktop for example or into visible and iconified etc. etc. windows would be nice. > Also, how about this one: > > * desktop flip animations need to allow control over accel/decel and > have a better ui - add wobble and controls etc. etc. > > > Seems to me this is done? There are controls for type of animation and > its speed, via Config -> screen -> virtual desktop. Is that not what > this item is referring to? I don't understand "wobble". That a new > transistion type? most of this is done - but there are more things to do - right now it just slides until done - it would be nice to have a bit more control over the final destination - it overshoots then slides back a bit - wobbling around the destination a bit like how thumbnails appear in fm2 > And finally this one: > > * internal windows (config dialogs, etc) should re-open after a restart > > Just wondering *why* this is desired. Seems like a lot of book > keeping... for little value. Just wondering what the motivation for > this one was. change theme - and dialog goes away. bad. people dont realise e actually restarted and wonder why dialogs would go away. > Thanks. :) > > -- > Regards, > Ravenlock > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] TODO item(s) need clarification.....
On Fri, 16 Mar 2007 15:55:37 -0500 Eric Schuele <[EMAIL PROTECTED]> babbled: > On 03/16/2007 15:26, Brian Mattern wrote: > > On Fri, Mar 16, 2007 at 09:10:56AM -0500, Eric Schuele wrote: > >> hehe... a wobble transistion. cool. you think each window individually > >> should wobble or the entire desktop? > > > > More like when you switch desktops, the old desktop's windows immediately > > disappear, and the new desktop's windows appear, but wobble for a > > second. > > > > However, I don't see how this would be possible without a compositor. > > > > While on the topic of desktop transitions does anyone else notice that > > e17's seem pretty slow? they get choppy when i have large and/or many > > windows (on an athlon 64 3000+). e16 handled sliding windows beautifully > > on an 800mhz box... > > yes. I have noticed this. Thought it was simply my graphics adapter > wasn't keeping up. Sloow and choppy, even on my 2.66Ghz P4 laptop. turn off dropshadow and watch it get smooth. dropshadow is not cheap. > > > > rephorm > > > > > > - > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > -- > Regards, > Eric > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Desklock's idle timer....
On 03/21/2007 04:47, Carsten Haitzler (The Rasterman) wrote: > On Mon, 19 Mar 2007 00:50:26 -0500 Ravenlock <[EMAIL PROTECTED]> babbled: > >> Hello, >> >> The desklock's idle timer was apparently broken from the start. >> Keyboard activity was not considered when determining if the user was >> active or not. >> >> Here are some patches which fix this. With these patches a persons >> keyboard and mouse activity are both taken into consideration when >> determining if the user is active. >> >> This implementation requires that the XScreensaver extension be present. >> This is the "easy" fix. If the powers that be prefer that this >> functionality *not* depend on the XScreensaver extension, well... then >> its a bigger problem. >> >> Questions/comments/complaints welcome. :) > > actually desklocks idle thing has always been broken. the e_manage though uses > the xscreensaver events in _e_manager_cb_screensaver_notify() to turn on > desklock if the screensaver kicks in :) > *That* timer still exists. However, I created a new timer that was separate from that which will allow a user to "lock" the screen either before or after the X screesaver, or at the same time as some other third party saver. That timer was not functioning properly. I am hoping this patch fixes the problem I introduced. >> -- >> Regards, >> Ravenlock >> > > -- Regards, Ravenlock - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [ENM] A network manager front end
On Sun, 18 Mar 2007 18:15:59 +0100
watchwolf <[EMAIL PROTECTED]> wrote:
> hello,
>
> I want present you a new application writed with etk for E17.
> The application can have some bugs for you as segv :p . The code is
> not perfect, I need to add some tests & errors outputs. The next
> steps, before add new functions, is to clean/correct the code.
>
> You can see screenshots & the source code on my blog.
> http://watchwolf.fr/index.php?post/2007/03/18/%5BE17-Network-manager%
> 5D-Pesentation
>
> To compile us this makefile: etk/Makefile.
>
I couldn't get the binary to run as I don't have Ecore compiled with
fbcon support.
I also think you got a older ETK, I had to fiddle a bit with the
combobox bit in general_panel.c to get it working(Attached, but I'm
not sure if this is doing it right).
Looking good thou, too bad I'm not wireless so I could throughly test
it out.
--- src/general_panel.c 2007-03-21 12:45:19.0 +
+++ ../../enm_18_03_07/etk/src/general_panel.c 2007-03-18 15:21:26.0 +
@@ -22,8 +22,8 @@
etk_box_append(ETK_BOX(hbox),label,ETK_BOX_START, ETK_BOX_NONE,0);
pnl->cmbox_ethernet = etk_combobox_new();
- etk_combobox_column_add(ETK_COMBOBOX(pnl->cmbox_ethernet), ETK_COMBOBOX_IMAGE, 25, ETK_FALSE, ETK_FALSE, ETK_FALSE, 0.0, 0.5);
- etk_combobox_column_add(ETK_COMBOBOX(pnl->cmbox_ethernet), ETK_COMBOBOX_LABEL, 25, ETK_TRUE, ETK_FALSE, ETK_FALSE, 0.0, 0.5);
+ etk_combobox_column_add(ETK_COMBOBOX(pnl->cmbox_ethernet), ETK_COMBOBOX_IMAGE, 25, ETK_COMBOBOX_FILL, 0.5);
+ etk_combobox_column_add(ETK_COMBOBOX(pnl->cmbox_ethernet), ETK_COMBOBOX_LABEL, 25, ETK_COMBOBOX_NONE, 0.5);
etk_combobox_build(ETK_COMBOBOX(pnl->cmbox_ethernet));
etk_box_append(ETK_BOX(hbox), pnl->cmbox_ethernet, ETK_BOX_START, ETK_BOX_NONE, 0);
etk_signal_connect("active_item_changed", ETK_OBJECT(pnl->cmbox_ethernet), ETK_CALLBACK(generalpanel_cmboxethernet_active_item_changed_cb), pnl);
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [ENM] A network manager front end
On Wed, 2007-03-21 at 12:57 +, Nils Larsson wrote: > On Sun, 18 Mar 2007 18:15:59 +0100 > watchwolf <[EMAIL PROTECTED]> wrote: > > > hello, > > > > I want present you a new application writed with etk for E17. > > The application can have some bugs for you as segv :p . The code is > > not perfect, I need to add some tests & errors outputs. The next > > steps, before add new functions, is to clean/correct the code. > > > > You can see screenshots & the source code on my blog. > > http://watchwolf.fr/index.php?post/2007/03/18/%5BE17-Network-manager% > > 5D-Pesentation > > > > To compile us this makefile: etk/Makefile. > > > I couldn't get the binary to run as I don't have Ecore compiled with > fbcon support. > > I also think you got a older ETK, I had to fiddle a bit with the > combobox bit in general_panel.c to get it working(Attached, but I'm > not sure if this is doing it right). > It s because I used a older version of etk. > Looking good thou, too bad I'm not wireless so I could throughly test > it out. > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ enlightenment-devel mailing > list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- powered by gnu/linux - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Pending patch
I have also some patch that are still waiting their way to the CVS.
- edje_font_hash.diff: Use Evas_Hash for font lookup.
After upgrading my ubuntu, I experienced the same bug raster
experienced on
his machine (all dialog box where empty). I was able to find it in
_edje_font_is_embedded from edje_textblock_styles.c.
static int
_edje_font_is_embedded(Edje_File *edf, char *font)
{
Evas_List *l;
if (!edf->font_dir) return 0;
for (l = edf->font_dir->entries; l; l = l->next)
{
Edje_Font_Directory_Entry *fnt = l->data;
if ((fnt->entry) && (!strcmp(fnt->entry, font)))
return 1;
}
return 1;
}
I read this function too quickly, and didn't see that it really only
check
edf->font_dir. The rest was only here to slow every thing :) So now the patch
must work correctly.
- evas_list_sort_inplace.diff: Replace the merge sort algorithm with an in
place merge sort.
I don't remember why it didn't get inside but I am using it in my own
code
without problem and it's fast. If I have time, I should port this to
ecore_list_sort.
- evas_tiler_speedup.diff: Walk progressively over the Tilebuf_Tile.
In some of my test I did notice that this function could take some time
(It
was with moving evas rectangle if I remember correctly). I basically took the
costly operation out of the loop.
Cedric
diff -Nrua -X /home/cedric/.diff.rc e17-main/libs/edje/src/lib/edje_cache.c e17-base/libs/edje/src/lib/edje_cache.c
--- e17-main/libs/edje/src/lib/edje_cache.c 2007-03-19 23:46:46.0 +0100
+++ e17-base/libs/edje/src/lib/edje_cache.c 2007-03-20 17:55:55.0 +0100
@@ -63,6 +63,32 @@
return edc;
}
+static int
+_edje_font_hash (Edje_File *edf)
+{
+ int count = 0;
+
+ if (edf->font_dir)
+ {
+ Evas_List *l;
+ for (l = edf->font_dir->entries; l; l = evas_list_next (l))
+ {
+ Edje_Font_Directory_Entry *fnt = l->data;
+ int length = strlen (fnt->entry) + 7;
+ char *tmp = alloca (length);
+
+ snprintf (tmp, length, "fonts/%s", fnt->entry);
+ fnt->path = evas_stringshare_add (tmp);
+ evas_stringshare_del (fnt->entry);
+ fnt->entry = fnt->path + 6;
+ edf->font_hash = evas_hash_direct_add (edf->font_hash, fnt->entry, fnt);
+
+ count++;
+ }
+ }
+ return count;
+}
+
static Edje_File *
_edje_file_open(const char *file, const char *coll, int *error_ret, Edje_Part_Collection **edc_ret)
{
@@ -112,18 +138,19 @@
}
edf->data = NULL;
- if (!coll)
+ if (coll)
{
- eet_close(ef);
- return edf;
+ edc = _edje_file_coll_open(edf, ef, coll);
+ if (!edc)
+ {
+ *error_ret = EDJE_LOAD_ERROR_UNKNOWN_COLLECTION;
+ }
+ if (edc_ret) *edc_ret = edc;
}
+
+ edf->font_hash = NULL;
- edc = _edje_file_coll_open(edf, ef, coll);
- if (!edc)
- {
- *error_ret = EDJE_LOAD_ERROR_UNKNOWN_COLLECTION;
- }
- if (edc_ret) *edc_ret = edc;
+ _edje_font_hash (edf);
eet_close(ef);
diff -Nrua -X /home/cedric/.diff.rc e17-main/libs/edje/src/lib/edje_calc.c e17-base/libs/edje/src/lib/edje_calc.c
--- e17-main/libs/edje/src/lib/edje_calc.c 2007-03-20 13:47:23.0 +0100
+++ e17-base/libs/edje/src/lib/edje_calc.c 2007-03-20 17:42:40.0 +0100
@@ -602,7 +602,6 @@
const char *font;
int size;
Evas_Coord tw, th;
- char buf[4096];
int inlined_font = 0;
/* Update a object_text part */
@@ -683,24 +682,14 @@
if (!text) text = "";
/* check if the font is embedded in the .eet */
-/* FIXME: we should cache this result */
-if (ed->file->font_dir)
+if (ed->file->font_hash)
{
- Evas_List *l;
-
- for (l = ed->file->font_dir->entries; l; l = l->next)
- {
- Edje_Font_Directory_Entry *fnt = l->data;
+ Edje_Font_Directory_Entry *fnt = evas_hash_find (ed->file->font_hash, font);
- if ((fnt->entry) && (!strcmp(fnt->entry, font)))
- {
- strcpy(buf, "fonts/");
- strncpy(buf + 6, font, sizeof(buf) - 7);
- buf[sizeof(buf) - 1] = 0;
- font = buf;
- inlined_font = 1;
- break;
- }
+ if (fnt)
+ {
+ font = fnt->path;
+ inlined_font = 1;
}
}
if (inlined_font) evas_object_text_font_source_set(ep->object, ed->path);
diff -Nrua -X /home/cedric/.diff.rc e17-main/libs/edje/src/lib/edje_load.c e17-base/libs/edje/src/lib/edje_load.c
--- e17-main/libs/edje/src/lib/edje_load.c 2007-03-19 23:46:46.0 +0100
+++ e17-base/libs/edje/src/lib/edje_load.c 2007-03-20 17:42:40.0 +0100
@@ -640,9 +640,10 @@
Edje_Font_Directory_Entry *fe;
fe = edf->font_dir->entries->data;
- edf->font_dir->entries =
+ edf->font_dir->entries =
evas_list_remove_list(edf->font_dir->entries, edf->font_dir->entries);
- if (fe->entry) evas_stringshare_del(fe->entry);
+ edf->font_hash = evas_hash_del(edf->font_hash, fe->entry, NULL);
+ if (fe->path) evas_string
[E-devel] [RFC] Events
Another discussion, this time about events. During my test of SDL engine, I
did like the key repeat functionnality of SDL, but it wasn't possible to
easily expose it to evas. So I just added a EVAS_CALLBACK_KEY_REPEAT with the
corresponding 'evas_event_feed_key_repeat'. It seems quite logic and work.
See evas_key_repeat.diff.
I don't know what is the policy for adding new events, but SDL could
also
expose some Joystick events:
SDL_JoyAxisEvent -- Joystick axis motion event structure
SDL_JoyButtonEvent -- Joystick button event structure
SDL_JoyHatEvent -- Joystick hat position change event structure
SDL_JoyBallEvent -- Joystick trackball motion event structure
Would people object if I come up with some evas event for this also ? This
would be nice, if an Ecore SDL was able to directly feed them to evas. But I
will understand that it's not the primary usage/goal of evas.
On the same subject, it would also be nice if we could handle multiple
device
easily in evas. From what I see, the only thing that is needed is a 'char*
device' in all struct _Evas_Event and breaking all evas_event_feed functions
prototype by adding a device parameter. The device could be set to NULL, so
all existing code will still work with very few modification (mainly in
ecore).
Would people be interested/object to this kind of patch ?
Cedric
diff -Nrau -x '*.lo' -x '*.la' -x doc -x Makefile -x Makefile.in -x CVS -x autom4te.cache -x '*.o' -x 'config.*' -x configure -x .deps -x .libs e17-main/libs/evas/src/lib/canvas/evas_events.c e17-dev/libs/evas/src/lib/canvas/evas_events.c
--- e17-main/libs/evas/src/lib/canvas/evas_events.c 2006-12-26 11:57:37.0 +0100
+++ e17-dev/libs/evas/src/lib/canvas/evas_events.c 2007-03-13 11:42:53.0 +0100
@@ -518,6 +518,7 @@
else
outs = evas_list_append(outs, obj);
}
+
if (copy) copy = evas_list_free(copy);
while (outs)
{
@@ -857,6 +858,90 @@
*
*/
EAPI void
+evas_event_feed_key_repeat(Evas *e, const char *keyname, const char *key, const char *string, const char *compose, unsigned int timestamp, const void *data)
+{
+ MAGIC_CHECK(e, Evas, MAGIC_EVAS);
+ return;
+ MAGIC_CHECK_END();
+ if (!keyname) return;
+ if (e->events_frozen > 0) return;
+ e->last_timestamp = timestamp;
+ {
+ Evas_Event_Key_Repeat ev;
+ int exclusive;
+
+ exclusive = 0;
+ ev.keyname = (char *)keyname;
+ ev.data = (void *)data;
+ ev.modifiers = &(e->modifiers);
+ ev.locks = &(e->locks);
+ ev.key = key;
+ ev.string = string;
+ ev.compose = compose;
+ ev.timestamp = timestamp;
+ if (e->grabs)
+ {
+ Evas_List *l;
+
+ e->walking_grabs++;
+ for (l = e->grabs; l; l= l->next)
+ {
+ Evas_Key_Grab *g;
+
+ g = l->data;
+ if (g->just_added)
+ {
+ g->just_added = 0;
+ continue;
+ }
+ if (g->delete_me) continue;
+ if (((e->modifiers.mask & g->modifiers) ||
+ (g->modifiers == e->modifiers.mask)) &&
+ (!strcmp(keyname, g->keyname)))
+ {
+ if (!(e->modifiers.mask & g->not_modifiers))
+ {
+ if (e->events_frozen <= 0)
+ evas_object_event_callback_call(g->object, EVAS_CALLBACK_KEY_REPEAT, &ev);
+ if (g->exclusive) exclusive = 1;
+ }
+ }
+ }
+ e->walking_grabs--;
+ if (e->walking_grabs <= 0)
+ {
+ while (e->delete_grabs > 0)
+ {
+ Evas_List *l;
+
+ e->delete_grabs--;
+ for (l = e->grabs; l;)
+ {
+ Evas_Key_Grab *g;
+
+ g = l->data;
+ l = l->next;
+ if (g->delete_me)
+ evas_key_grab_free(g->object, g->keyname, g->modifiers, g->not_modifiers);
+ }
+ }
+ }
+ }
+ if ((e->focused) && (!exclusive))
+ {
+ if (e->events_frozen <= 0)
+ evas_object_event_callback_call(e->focused, EVAS_CALLBACK_KEY_REPEAT, &ev);
+ }
+ }
+}
+
+/**
+ * To be documented.
+ *
+ * FIXME: To be fixed.
+ *
+ */
+EAPI void
evas_event_feed_key_up(Evas *e, const char *keyname, const char *key, const char *string, const char *compose, unsigned int timestamp, const void *data)
{
MAGIC_CHECK(e, Evas, MAGIC_EVAS);
diff -Nrau -x '*.lo' -x '*.la' -x doc -x Makefile -x Makefile.in -x CVS -x autom4te.cache -x '*.o' -x 'config.*' -x configure -x .deps -x .libs
e17-main/libs/evas/src/lib/Evas.h e17-dev/libs/evas/src/lib/Evas.h
--- e17-main/libs/evas/src/lib/Evas.h 2007-03-19 23:49:59.0 +0100
+++ e17-dev/libs/evas/src/lib/Evas.h 2007-03-19 19:00:39.0 +0100
@@ -37,6 +37,7 @@
EVAS_CALLBACK_MOUSE_WHEEL, /**< Mouse Wheel Event */
EVAS_CALLBACK_FREE, /**< Object Being Freed */
EVAS_CALLBACK_KEY_DOWN, /**< Key Press Event */
+ EVAS_CALLBACK_KEY_REPEAT, /**< Key Repeat Event */
EVAS_CALLBACK_KEY_UP, /**< Key Release Event */
EVAS_CALLBACK_FOCUS_IN, /**< Focus In Event */
EVAS_CALLBACK_FOCUS_OUT, /**< Focus Out Event */
@@ -133,6 +134,7 @@
typedef struct _Evas_Event_Mouse_Move Evas_Even
Re: [E-devel] [RFC] SDL Engine
On 3/21/07, Cedric BAIL <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I finally got a SDL Engine running and starting to look correct. I > did split > it in 3 patch. > > - evas_cache_image.diff: Add a global cache for image mechanism. > I hope it could be shared with other engine and reduce their code > complexity. > This cache works more like the one from FreeType, you request image/operation > from the cache, and the cache forwards it if needed to the right callback > function. This need to be carefully reviewed, even if it seems correct. > I also included in this patch a new > 'evas_common_load_image_module_from_file' > function that just create the RGBA_Image without any cache manipulation. I > also updated 'evas_common_load_image_from_file' function to use it. > > - evas_sdl_engine.diff: This patch really provides the SDL engine. > You must not expect other colorspace than EVAS_COLORSPACE_ARGB to > work. I > have no plan to fix this now as I think it will be easier to test that with > emotion. So I first need an Ecore_SDL to fix this. > It doesn't use evas_pipe (and never will) as it need to use SDL > thread to do > that same task, and I am really not planing to do it soon. > > - evas_sdl_test.diff: Add an old style evas test for SDL engine. > Every test must work, if not please report bugs to me :) Great to see it happen. I'm about to write an engine to carry operations in 16bpp and had already noticed this code duplication, so this helps me a bit :-) My idea is similar to SDL_ConvertSurface(), however I plan to handle alpha transparency too... we do it with Canola/SDL and performance is incredible faster[*] than 32bpp->16bpp at every blit. My aim is to have a pure-x11 engine, fixed for 16bpp, avoiding overheads. However, with your engine at hand it should be much easier to evaluate how well it work. Do you plan to add this bit-depth support for it? [*] http://lists.libsdl.org/pipermail/sdl-libsdl.org/2001-April/016483.html Blit565to565SurfaceAlpha(): If you opt to drop quality in favor of performance, you can pack r5g6b5 inside one 32bits word and use 5bit-Alpha, doing add or multiply of 3 channels with one operation. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wednesday 21 March 2007 18:18:41 you wrote: > On 3/21/07, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > Hi everybody, > > > > I finally got a SDL Engine running and starting to look correct. > > I did split it in 3 patch. > > > > - evas_cache_image.diff: Add a global cache for image mechanism. > > I hope it could be shared with other engine and reduce their code > > complexity. This cache works more like the one from FreeType, you request > > image/operation from the cache, and the cache forwards it if needed to > > the right callback function. This need to be carefully reviewed, even if > > it seems correct. I also included in this patch a new > > 'evas_common_load_image_module_from_file' function that just create the > > RGBA_Image without any cache manipulation. I also updated > > 'evas_common_load_image_from_file' function to use it. > > > > - evas_sdl_engine.diff: This patch really provides the SDL engine. > > You must not expect other colorspace than > > EVAS_COLORSPACE_ARGB to work. I have no plan to fix this now as I > > think it will be easier to test that with emotion. So I first need an > > Ecore_SDL to fix this. > > It doesn't use evas_pipe (and never will) as it need to use SDL > > thread to do that same task, and I am really not planing to do it soon. > > > > - evas_sdl_test.diff: Add an old style evas test for SDL engine. > > Every test must work, if not please report bugs to me :) > > Great to see it happen. > > I'm about to write an engine to carry operations in 16bpp and had > already noticed this code duplication, so this helps me a bit :-) Great to see this could help others. > My idea is similar to SDL_ConvertSurface(), however I plan to handle > alpha transparency too... we do it with Canola/SDL and performance is > incredible faster[*] than 32bpp->16bpp at every blit. > My aim is to have a pure-x11 engine, fixed for 16bpp, avoiding > overheads. However, with your engine at hand it should be much easier > to evaluate how well it work. Do you plan to add this bit-depth > support for it? Well my TODO is quite huge at the moment, and I first want to have it integrated with ecore and emotion able to run with this engine. So I must admit that such optimization are really low priority on my list even if I like the idea, but if you have time to add this, it will be great. > [*] http://lists.libsdl.org/pipermail/sdl-libsdl.org/2001-April/016483.html > Blit565to565SurfaceAlpha(): If you opt to drop quality in favor of > performance, you can pack r5g6b5 inside one 32bits word and use > 5bit-Alpha, doing add or multiply of 3 channels with one operation. Interesting patch, I like the idea, sad I don't have all the time I need :) Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] forecast's popup, to popup on a click (configurable)...
On 03/21/2007 01:05, Виктор Кожухаров wrote: > В вт, 2007-03-20 в 22:07 -0500, Ravenlock написа: >> Hello, >> >> I, just this evening, started using the forecast module. I like it very >> much. >> >> However, I find that the popup... popping up on a hover is terribly >> annoying. Its annoying for me because I like to keep it in the upper >> right corner of my screen. Being there, every time I minimize a >> window... I am then hovering over it, and it pops up. :( >> >> So I wanted to have an option to have the popup window popup on either a >> mouse in or a mouse down. >> >> The attached patch alters the config panel, and provides a way to >> disable the "popup on hover". If "popup on hover" is unchecked, the >> popup will appear on a mouse down, and stay pinned. A second mouse down >> will hide it. >> >> PLEASE NOTE: >> This patch also changes the default popup behavior to popup on the mouse >> down. This is by design. My argument for doing it this way is... The >> original was not a popup on *hover*... but popup immediately on a mouse >> in. This meant that if you just passed over it carelessly... it popped >> up. That bothered me too. A timer, to create a short "hover" delay >> would be necessary to make the hover work properly, imho. >> >> I hope someone finds this useful. :) > Thanks. I'm going to take a look at it. Thanks for considering the patch. :) > However, the default behavior is > going to stay, so I'll have to change the logic of the patch to turn off > the popup at mouse in, instead of turning it on. I wrote no code to change the default behavior. It was changed simply because the int I use is initialized to zero, thus turning the "popup on hover" off". I can change and resubmit if you like. :) > And an immediate popup > at mouse in is important, since people tend to want information > immediately, instead of having to wait for a timer to time out :) Understood. I did not add a timer... it was just a thought. But fwiw... I mean a timer that waited and made sure the pointer had at least come to a rest, for say a quarter second. Or at least stopped moving. As opposed to simply be moving through the same space. Just an idea. > > p.s. And practice your mouse control, it sounded like you triggered the > popup one too many times :) > > > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards, Eric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
> Hi everybody, > > I finally got a SDL Engine running and starting to look > correct. I did split it in 3 patch. > > Wow. That's remarkable work Cedric. :) I have a very 'naive' question for you though: What exactly is "SDL", and why do people find it an interesting dsiplay target/ rendering engine... ?? jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E and gui-toolkits.
I'd like to bring up some things about 'e' and gui-toolkits. I know this has been a source of some friction here before, but I'd like to be able to discuss various aspects in a serious and rational way.. Hopefully, the toolkit devs themselves will be able to help in this and see areas of interest they'd like to bring up. There are many aspects to something as complex as a high- level gui-toolkit lib, but one that is important for 'e' is "themability". This allows for consistent and yet variable 'look& feel' for apps built with them. I wonder though if one can write apps with e's toolkits that would allow for 'overriding' the toolkit's theme (with an app-provided edje goup say), for a given toolkit widget? Also, is it possible to build 'custom widgets' that can be given app-specific theming? Just how flexible can/should 'theming' be? In a slightly different vein.. Is there something like the equivalent of e17's modules for the gui-toolkits -- does something like that even make sense? There are of course many other aspects of interest, not necessarily related to theming, and I wonder if the toolkit devs have any thoughts or ideas they feel would be interesting, or things they feel 'e' should support, ... eg. I've sometimes seen references to kde's "kio slaves" and "kparts"... Can anyone tell me exactly what these things are and why they are considered useful? Are these kinds of things something that a gui-toolkit should have, or are they more like an ecore-lib? Is there a coherent relationship between such things and say e_dbus, evfs, ?? Much of this looks like a kind of multi-tiered jigsaw-puzzle to me... What is the "big picture" here? And how do the "pieces" fit together? jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
On Wed, 21 Mar 2007 21:36:08 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I have a very 'naive' question for you though: What exactly > is "SDL", and why do people find it an interesting dsiplay target/ > rendering engine... ?? http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer signature.asc Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
[EMAIL PROTECTED] wrote: > I wonder though if one can write apps with e's toolkits > that would allow for 'overriding' the toolkit's theme (with an > app-provided edje goup say), for a given toolkit widget? Also, is it > possible to build 'custom widgets' that can be given app-specific > theming? Just how flexible can/should 'theming' be? > Ewl allows you to override the theme as needed. You can either a) write your own theme and use that to display, or b) you can override theme keys on the fly to add or remove theming as needed. Ewl uses a hierarcy of theme keys so you can be very specific in what you want to override. If you only want your buttons inside your hbox inside your window to change you can override /window/hbox/button/group and point it to a different theme group. The app doesn't need to know anything about the theme, it just needs to know the widget hierarchy that it's overridding (which it can trivially discover with --ewl-print-theme-keys on the command line.) The themes work by defining a data section in the main edc file that gives the key mappings for the theme itself. > In a slightly different vein.. Is there something like the > equivalent of e17's modules for the gui-toolkits -- does something > like that even make sense? > Ewl has several pieces that are pluggable. You can add your own widgets, epdf does this to create an Ewl_Widget. You can add engines which Ewl will discover at runtime, the engines are also inheritable so you only need to write the pieces that are different. You can add IO Managers (these are still very much in flux and the API _will_ change.) You can also provide different views for the Ewl_Filepicker widget. (We use this to provide icon, list and column views.) The same view concept is used in the tree to allow us a plain display or a scrolled display. > There are of course many other aspects of interest, not > necessarily related to theming, and I wonder if the toolkit > devs have any thoughts or ideas they feel would be interesting, > or things they feel 'e' should support, ... > eg. I've sometimes seen references to kde's "kio slaves" > and "kparts"... Can anyone tell me exactly what these things are > and why they are considered useful? Are these kinds of things > something that a gui-toolkit should have, or are they more like > an ecore-lib? Is there a coherent relationship between such things > and say e_dbus, evfs, ?? > kio slaves I take to be more inline with evfs. Evfs could be used by the Ewl filpicker widget but I believe there were some issues getting it to work on OSX, can't remember exactly. Kparts, at least my understanding, is that their just bigger, more complicated widgets? Ewl will be using e_dbus I think in the future to handle sending out configuration change notifications. This hasn't been built in yet, but it used to do this using the ecore_config IPC mechanism. dan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On 3/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'd like to bring up some things about 'e' and gui-toolkits. > I know this has been a source of some friction here before, but > I'd like to be able to discuss various aspects in a serious and > rational way.. Hopefully, the toolkit devs themselves will be able > to help in this and see areas of interest they'd like to bring up. No problem, I'll stock up on burn cream tonight, and try to limit myself to commenting on what I specifically know (EWL). > I wonder though if one can write apps with e's toolkits > that would allow for 'overriding' the toolkit's theme (with an > app-provided edje goup say), for a given toolkit widget? Also, is it > possible to build 'custom widgets' that can be given app-specific > theming? In EWL, you can set the theme data on a widget and override a specific key for that widget and all widgets contained in it. dan covered this in more detail, but we also have a test application that outlines one way to interact with a custom edje, it's available in ewl/src/bin/ewl_embed_test.c. > Just how flexible can/should 'theming' be? This last question is actually one of the most difficult parts of writing a toolkit around edje, it's a big balancing act. You can easily get wrapped up in theme-ability and kill consistency and performance, or make large sacrifices in theming to balance back the other direction, the middle ground is not trivial. I can outline a couple of the decisions we've made in EWL. Overall, we have taken the attitude that the GUI toolkit is used specifically for describing layouts with hints from the theme but not completely controlled by it, and as such, EWL is more like GTK+, QT, Swing, etc. I have looked at pushing some more responsibility into the theme, but I think it will complicate things to a degree I don't want to deal with until we've stabilized other aspects more. We also maintain some limited state information inside of the EWL widgets to allow for rebuilding edje object states as they are created or re-used. Because of this, we only have edje objects for the widgets that are currently visible in the window. This keeps the memory use down considerably as the number of widgets grows, and actually reduces CPU use as well, since the Evas rendering passes require less object traversal. We are actually able to easily outpace GTK+ in the CPU time and memory required to display a large number of widgets in a trivial scalability test. The downside of this trade-off is that we cannot rely on transient states inside of the Edje objects, so complex layouts and scripts may not behave as you'd like. > In a slightly different vein.. Is there something like the > equivalent of e17's modules for the gui-toolkits -- does something > like that even make sense? External libraries should be able to easily provide additional widgets, though we make no guarantees on API let alone ABI stability yet. I don't see much benefit to pushing a loading mechanism specifically into EWL at this time, as the application taking advantage of outside modules should be aware of its dependencies. This seems like a higher level function, like the KParts you mention below. > eg. I've sometimes seen references to kde's "kio slaves" > and "kparts"... Can anyone tell me exactly what these things are > and why they are considered useful? Are these kinds of things > something that a gui-toolkit should have, or are they more like > an ecore-lib? Is there a coherent relationship between such things > and say e_dbus, evfs, ?? A good description of KIO is available on wikipedia: http://en.wikipedia.org/wiki/KIO As I understand, it's more like evfs than a toolkit layer. KParts on the other hand is like a communication layer for embedding higher level widgets inside applications. http://en.wikipedia.org/wiki/KPart > Much of this looks like a kind of multi-tiered jigsaw-puzzle > to me... What is the "big picture" here? And how do the "pieces" fit > together? A puzzle is a fairly good analogy, if you had pieces that overlapped one another and some that just didn't exist. :) Not only do we have the multiple toolkits, but we also have some widget-like features inside of Evas, Edje and some container features in Esmart. There are engine layers in evas, ecore, EWL and ETK, and IO mechanisms in Ecore, Ecore_File, EVFS, and EWL (though this is more for convenience for interfacing with widgets than a true IO API). At this point, I would say the big picture looks something like Trogdor. Nathan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel m
Re: [E-devel] E and gui-toolkits.
On Wed, 21 Mar 2007 21:37:12 GMT, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote : > > I'd like to bring up some things about 'e' and gui-toolkits. > I know this has been a source of some friction here before, but > I'd like to be able to discuss various aspects in a serious and > rational way.. Hopefully, the toolkit devs themselves will be able > to help in this and see areas of interest they'd like to bring up. > > There are many aspects to something as complex as a high- > level gui-toolkit lib, but one that is important for 'e' is > "themability". This allows for consistent and yet variable 'look& > feel' for apps built with them. > I wonder though if one can write apps with e's toolkits > that would allow for 'overriding' the toolkit's theme (with an > app-provided edje goup say), for a given toolkit widget? Also, is it > possible to build 'custom widgets' that can be given app-specific > theming? Just how flexible can/should 'theming' be? In Etk, as in Ewl I think, you can change the theme of a specific widget or change globally the theme used by all the widgets. About custom widgets, it's indeed possible to build your own widget directly in the app's code, the only difficulty here will be the themability: either you use theme-parts from existing widgets and there will be no problem, or you use your own theme-file for this widget but it may look wrong with some Etk/Ewl themes. > In a slightly different vein.. Is there something like the > equivalent of e17's modules for the gui-toolkits -- does something > like that even make sense? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as "modules" (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. > There are of course many other aspects of interest, not > necessarily related to theming, and I wonder if the toolkit > devs have any thoughts or ideas they feel would be interesting, > or things they feel 'e' should support, ... There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Toolkits are nice for config dialogs or for apps that need to offer a lot of control. If we really want to have a nice and innovative Enlightenment desktop environment, we should be different from the other desktop environments. We should have apps with a really nice and well-designed interface, and most of the time, this is just not possible with a toolkit. Elicit is a good example of an innovative application that blows your mind away when you first launch it. If it were using Etk or Ewl, it would just have been a common application. I just wish that when someone will want to start a new application, he will consider making it using Edje and not jumping directly on Etk or Ewl. Or Enlighenment apps will just be a copy of Gnome/Kde apps (with some glint on the buttons though :)) Simon TRENY > eg. I've sometimes seen references to kde's "kio slaves" > and "kparts"... Can anyone tell me exactly what these things are > and why they are considered useful? Are these kinds of things > something that a gui-toolkit should have, or are they more like > an ecore-lib? Is there a coherent relationship between such things > and say e_dbus, evfs, ?? > > Much of this looks like a kind of multi-tiered jigsaw-puzzle > to me... What is the "big picture" here? And how do the "pieces" fit > together? > > jose. > > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief surveys-and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ enlightenment-devel > mailing list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics throug
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 00:10:33 +0100 Simon TRENY <[EMAIL PROTECTED]> wrote: > On Wed, 21 Mar 2007 21:37:12 GMT, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote : > > > There are of course many other aspects of interest, not > > necessarily related to theming, and I wonder if the toolkit > > devs have any thoughts or ideas they feel would be interesting, > > or things they feel 'e' should support, ... > There is something I'd like to discuss here although I'm not sure it's > really the right place to do so.. Since Etk and Ewl have begun to be > usable enough, there has been a lot of new apps using one of these > too. The thing is, too often those apps only copy existing apps and I > just don't think this the right way. A lot of these apps would have > been a lot better if they hadn't used a toolkit but if they had used > directly Edje (and using Etk/Ewl only for the config dialogs). For > example, if we want to have a nice, original and innovative image > viewer, I really think its main interface should be directly coded > with Edje (like what entice did but in a more complete way). Same > thing for a filemanager, for an audio/video player or for an IM > client... Like the recently committed rage video player for instance. signature.asc Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] SDL Engine
and not only games, but a lot of softwares, like image processing,
special effects and videoconferencing (my work for now :) )
--
<< || 11 | 01 | 07 || >>
EPISODIO 3 LANCADO! - Luna F; Parte2
:: :: CyberEnvironment :: ::
}]| www.mdkcore.da.ru |[{
--
"Na União Soviética, o e-mail escreve VOCÊ!!"
~ Reversal Russa sobre "Escrever e-mail"
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On 21-Mar-07, at 7:10 PM, Simon TRENY wrote: > In Etk, as in Ewl I think, you can change the theme of a specific > widget or change globally the theme used by all the widgets. > About custom widgets, it's indeed possible to build your own widget > directly in the app's code, the only difficulty here will be > the themability: either you use theme-parts from existing widgets and > there will be no problem, or you use your own theme-file for this > widget but it may look wrong with some Etk/Ewl themes. > Ewl will allow you to specify the .edj file on a per widget basis if desired. Each widget has a /file along with a /group key that can be set. dan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
From Nathan's, Simon's, and Dan's replies, it seems that both ewl and etk do have mechanisms for allowing app-specific theme overriding of the toolkit widgets, and in fairly general ways. Wow. So, one could write an app, to start with, that uses only the toolkit themes, and if desired one could then extend this to allow for further app-specific mods. Best of both worlds. Ok, could one take say raster's "rage" and do this? ie. could it be written with ewl/etk to use only (or mostly) the toolkit widgets/themes and then extend it to duplicate whatever its current theming? What about the same for say, "entrance"? Simon writes: > > In a slightly different vein.. Is there something like the > > equivalent of e17's modules for the gui-toolkits -- does something > > like that even make sense? > I'm not sure I understand what you mean here. You can have loadable > widgets from a library, but there is no such things as > "modules" (i.e. plugins that may change the behavior of an Etk > apps). It may be a good idea, but I don't really see a use for this > for now. Well, let's say 'gui-modules' as loadable libs that would provide additional interesting (but possibly somewhat more specific) functionality than buttons/menus/... For example, et's say we have an "rss" feed module, or a "wether/forecast" one, or just a "clock", ... and that these could be embedded in normal toolkit widgets (in a menu or bar or whatnot). Nathan writes: > This seems like a higher level function, like the KParts you mention > below. Ummm... Yeah, but possibly something more 'lightweight' would be good as well. I just took a quick look at "kparts", this seems to be a mechanism for allowing functionality that some apps may have to be shared by others. It seems to require that 'part' to be given as a loadable shared lib with certain kinds of interfaces that are known, and the rest (gui controls) to be specified in an xml file in certain ways. This is something that doesn't seem to need a source app at all, but likely obtained that way from existing ones. It also seems to me that this kind of thing could be achieved via a sufficiently extended notion of a 'vfs'. Anyway... it does seem to be a useful idea. Simon writes: > There is something I'd like to discuss here although I'm not sure > it's really the right place to do so.. Since Etk and Ewl have begun > to be usable enough, there has been a lot of new apps using one of > these too. The thing is, too often those apps only copy existing > apps and I just don't think this the right way. A lot of these apps > would have been a lot better if they hadn't used a toolkit but if > they had used directly Edje (and using Etk/Ewl only for the config > dialogs)... Ummm.. I know what you're trying to say.. But there are several sides to this. One is that most people will find it MUCH easier to use a toolkit, and that seems to me to be the way to start unless you want a mostly stand-alone app, and are very good with edje. If e can have nearly as many apps written in its toolkits as there are now for gtk.. then I'd say that alone would be great achievement! If indeed one can extend ewl/etk in the ways you mention, then one could later optionally extend the theming and/or widgetry to be as unique as desired - hence allowing for both app-unique and toolkit-common 'look&feel' for a large number of apps that people may be inclined to write. Nathan writes: > > Much of this looks like a kind of multi-tiered jigsaw-puzzle > > to me... What is the "big picture" here? And how do the "pieces" > > fit together? > > A puzzle is a fairly good analogy, if you had pieces that overlapped > one another and some that just didn't exist. :) > > At this point, I would say the big picture looks something like > Trogdor. Ahhh :) jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
