Re: [E-devel] E SVN: barbieri IN trunk/elementary: data/themes doc/widgets src/lib src/modules/access_output src/modules/test_map
Yay! This is COOL!
Btw, what does 'u' stands for in 'elu_xxx'?
Daniel Juyung Seo (SeoZ)
On Thu, Oct 6, 2011 at 7:18 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Elementary support for EWS, with simplistic window manager.
This contains a very simple and stupid window manager to be used in
FB, PS3 or similar single-window engines. Everybody is welcome to
improve it, particularly:
* Edje: better border decoration theme
* Edje: nice background
* C + Edje: taskbar with minimized items.
* C + Edje: find a better protocol to determine window size,
accounting border decoration without account shadow! Right now I'm
taking everything :-P
* C: window management keys (Alt+F4 and like)
How to use: export ELM_ENGINE=ews
How to configure backing store: export ECORE_EVAS_EWS=engine:x:y:w:h:options
Example:
{{{
export ECORE_EVAS_EWS=software_x11:0:0:1024:768
export ELM_ENGINE=ews
elementary_test
}}}
Bugs: maybe many, but so far seems it wouldn't take mouse events for
secondary windows. Will check it later.
Author: barbieri
Date: 2011-10-05 15:18:22 -0700 (Wed, 05 Oct 2011)
New Revision: 63849
Trac: http://trac.enlightenment.org/e/changeset/63849
Added:
trunk/elementary/data/themes/ews.edc trunk/elementary/src/lib/elu_ews_wm.c
Modified:
trunk/elementary/data/themes/Makefile.am
trunk/elementary/data/themes/default.edc trunk/elementary/doc/widgets/
trunk/elementary/src/lib/Elementary.h.in trunk/elementary/src/lib/Makefile.am
trunk/elementary/src/lib/elm_config.c trunk/elementary/src/lib/elm_main.c
trunk/elementary/src/lib/elm_priv.h trunk/elementary/src/lib/elm_theme.c
trunk/elementary/src/lib/elm_win.c
trunk/elementary/src/modules/access_output/
trunk/elementary/src/modules/test_map/
Modified: trunk/elementary/data/themes/Makefile.am
===
--- trunk/elementary/data/themes/Makefile.am 2011-10-05 22:11:00 UTC (rev
63848)
+++ trunk/elementary/data/themes/Makefile.am 2011-10-05 22:18:22 UTC (rev
63849)
@@ -60,6 +60,7 @@
widgets/entry.edc \
widgets/map.edc \
widgets/scroller.edc \
+ews.edc \
arrow_down.png \
arrow_up.png \
bar_shine.png \
Modified: trunk/elementary/data/themes/default.edc
===
--- trunk/elementary/data/themes/default.edc 2011-10-05 22:11:00 UTC (rev
63848)
+++ trunk/elementary/data/themes/default.edc 2011-10-05 22:18:22 UTC (rev
63849)
@@ -365,4 +365,6 @@
#include widgets/video.edc
#include widgets/naviframe.edc
+#include ews.edc
+
}
Property changes on: trunk/elementary/doc/widgets
___
Modified: svn:ignore
- Makefile.in
Makefile
.deps
widget_preview_layout
widget_preview_colorselector
widget_preview_fileselector
widget_preview_ctxpopup
widget_preview_hover
widget_preview_anchorview
widget_preview_diskselector
widget_preview_separator
widget_preview_conformant
widget_preview_entry1
widget_preview_entry2
widget_preview_entry3
widget_preview_entry4
widget_preview_icon
widget_preview_clock
widget_preview_flipselector
widget_preview_list
widget_preview_button1
widget_preview_button2
widget_preview_button3
widget_preview_index
widget_preview_calendar
widget_preview_label
widget_preview_image
widget_preview_hoversel
widget_preview_bg
widget_preview_flip
widget_preview_radio
widget_preview_check1
widget_preview_check2
widget_preview_check3
widget_preview_fileselector_entry
widget_preview_bubble1
widget_preview_bubble2
widget_preview_bubble3
widget_preview_actionslider
widget_preview_anchorblock
widget_preview_frame
widget_preview_fileselector_button1
widget_preview_fileselector_button2
widget_preview_pager
widget_preview_fileselector_button3
widget_preview_toggle
widget_preview_gengrid
widget_preview_panel
widget_preview_slider
widget_preview_genlist1
widget_preview_genlist2
widget_preview_genlist3
widget_preview_progressbar
widget_preview_genlist4
widget_preview_genlist5
widget_preview_slideshow
widget_preview_menu
widget_preview_inwin1
widget_preview_inwin2
widget_preview_inwin3
widget_preview_spinner
widget_preview_win
widget_preview_table
widget_preview_panes
widget_preview_scroller
widget_preview_box
widget_preview_segment_control
widget_preview_photocam
widget_preview_notify
widget_preview_toolbar
widget_preview_thumb
widget_preview_mapbuf
widget_preview_map
+ .deps
.libs
Makefile
Makefile.in
widget_preview_actionslider
widget_preview_anchorblock
widget_preview_anchorview
widget_preview_bg
widget_preview_box
widget_preview_bubble1
widget_preview_bubble2
widget_preview_bubble3
widget_preview_button1
widget_preview_button2
widget_preview_button3
widget_preview_calendar
widget_preview_check1
widget_preview_check2
widget_preview_check3
[E-devel] [PATCH] Bug fix for gengrid item size
This patch fixes a type-o bug in a recent gengrid commit that causes incorrect horizontal item positioning on horizontal gengrids. The problem is only visible when items are not square. I have observed that it fixes a problem I was having. Please review, thanks. Ben gengrid-item-size.patch Description: Binary data -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch] Evil, Configure.ac and Question.
Dear All, Hello!
[Patch]
The current configure.ac reset $win32-libs.
This patch will append additional value without reset.
Please review this and give any feedback.
[Question]
I have got a build error from ecore_con.c as following.
undefined reference to: inet_ntop();
In the Evil, inet_ntop() is defined evil_inet_ntop(); means as following
#define inet_ntop(x,y,z,s) evil_inet_ntop(x,y,z,s)
and ecore_con.c include Evil.h. So I think this is correct..
(inet_ntop() is defined and can be referenced)
but I have no idea why the build error comes.
Sincerely,
Shinwoo Kim.
Index: configure.ac
===
--- configure.ac (revision 63906)
+++ configure.ac (working copy)
@@ -99,19 +99,18 @@ AC_C___ATTRIBUTE__
win32_cppflags=-DEFL_EVIL_BUILD
win32_cflags=-Wall -Wextra -Wshadow -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
win32_cxxflags=
-win32_libs=
have_wince=no
case $host_os in
mingw32ce*)
have_wince=yes
win32_cppflags=${win32_cppflags} -D_WIN32_WCE=0x0420
-win32_libs=-ltoolhelp
+win32_libs=${win32_libs} -ltoolhelp
;;
*)
have_wince=no
win32_cxxflags=-fno-rtti -fno-exceptions
win32_cppflags=${win32_cppflags} -D_WIN32_WINNT=0x0501 -DSECURITY_WIN32
-win32_libs=-lpsapi
+win32_libs=${win32_libs} -lpsapi
;;
esac
AC_SUBST([win32_cppflags])
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Evil, Configure.ac and Question.
On Fri, 7 Oct 2011, cnook wrote: Dear All, Hello! [Patch] The current configure.ac reset $win32-libs. This patch will append additional value without reset. Please review this and give any feedback. fixed in svn. I changed your patch a bit to optimize DLL load. thank you [Question] I have got a build error from ecore_con.c as following. undefined reference to: inet_ntop(); In the Evil, inet_ntop() is defined evil_inet_ntop(); means as following #define inet_ntop(x,y,z,s) evil_inet_ntop(x,y,z,s) and ecore_con.c include Evil.h. So I think this is correct.. (inet_ntop() is defined and can be referenced) but I have no idea why the build error comes. Ha, maybe the reason is that I changed the location of the header files. Before, everything was installed in $includedir (certainly $prefix/include for you). Now, it is installed in $includedir/evil-0 And ecore includes the one in $includedir. I had that problem. Solution : if there are Evil header files in $includedir (Evil.h, evil_*.h), then delete them. Vincent -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Bug fix for gengrid item size
2011/10/7 Benjamin Drucker benjamin.t.druc...@alum.mit.edu This patch fixes a type-o bug in a recent gengrid commit that causes incorrect horizontal item positioning on horizontal gengrids. The problem is only visible when items are not square. I have observed that it fixes a problem I was having. Please review, thanks. Ben -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Thanks, in svn -- Michaël Bouchaud -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elm entry sizing issue
I'm away from home/computers until Saturday evening (leaving now), I'll
take a look at it soon after.
But I have a couple of questions until then:
What sizing do you get? what do you expect? The elm minimum height
should change according to the font size (unless it's smaller than the
finger size, which is then used).
--
Tom.
On 07/10/11 02:45, Ausmus, James wrote:
Hi All-
It appears that a standard Elementary entry widget has a minimum
height that it refuses to size beneath, regardless of the font size
being used, as demonstrated by the entry.c and entry.edc files below.
Is there any way around this? How can I get a short Elm entry that
actually obeys the size of the swallow - do I need to fully grok and
recreate the default Elm theme for an entry in order to reduce the min
height of it's visual components, or is there a (much) easier way? :)
Thanks!
-James
//
/*Begin entry.c */
#include stdio.h
#include Elementary.h
#include Edje.h
//UI signal callbacks
static Evas_Object *ly;
void main_quit_cb(void *data, Evas_Object *obj,
const char *emission, const char *source)
{
int x, y, h, w;
edje_object_part_geometry_get(elm_layout_edje_get(ly),
input_bg, x, y, w, h);
printf(after ibg geo: %i/%i, %i/%i\n, x, y, w, h);
edje_object_part_geometry_get(elm_layout_edje_get(ly),
input_swallow, x, y, w, h);
printf(after is geo: %i/%i, %i/%i\n, x, y, w, h);
elm_exit();
}
static Evas_Object* load_edj(Evas_Object *parent, const char *file,
const char *group)
{
Evas_Object *eo;
int r;
eo = elm_layout_add(parent);
if (eo) {
r = elm_layout_file_set(eo, file, group);
if (!r) {
evas_object_del(eo);
return NULL;
}
evas_object_size_hint_weight_set(eo,
EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
}
return eo;
}
int elm_main(int argc, char *argv[])
{
Evas_Object *win = NULL;
Evas_Object *tb;
int nw, nh;
/* create window */
win = elm_win_add(NULL, entry, ELM_WIN_BASIC);
if (win) {
elm_win_title_set(win, entry);
ecore_x_window_size_get(ecore_x_window_root_first_get(),
nw, nh);
evas_object_resize(win, nw, nh);
} else {
printf(couldn't create win!\n);
return -1;
}
/* load edje */
ly = load_edj(win, entry.edj, ui);
if (ly == NULL) {
printf(Couldn't create layout!\n);
return -1;
}
elm_win_resize_object_add(win, ly);
edje_object_signal_callback_add(elm_layout_edje_get(ly),
DONE_EXIT, *, main_quit_cb, NULL);
tb = elm_entry_add(ly);
if (tb) {
elm_entry_entry_set(tb, font size='4' color='white');
elm_entry_single_line_set(tb, EINA_TRUE);
elm_layout_content_set(ly, input_swallow, tb);
} else {
printf(Got null TB!\n);
return -1;
}
evas_object_show(ly);
evas_object_show(win);
elm_run();
elm_shutdown();
return 0;
}
ELM_MAIN();
/* End entry.c */
//
//
/* Begin entry.edc */
collections {
group {
name: ui;
parts {
part {
name: background;
type: RECT;
description {
state: default 0.0;
color: 0 0 0 100;
}
program {
name: background_clicked;
source: background;
signal: mouse,clicked,*;
action: SIGNAL_EMIT DONE_EXIT UI;
}
}
part {
name: input_bg;
type: RECT;
description {
state: default 0.0;
rel1 { relative: 0.37773 0.04375; }
rel2 { relative: 0.62227 0.06; }
color: 100 100 100 255;
Re: [E-devel] E SVN: barbieri IN trunk/elementary: data/themes doc/widgets src/lib src/modules/access_output src/modules/test_map
U for utility
On Friday, October 7, 2011, Daniel Juyung Seo seojuyu...@gmail.com wrote:
Yay! This is COOL!
Btw, what does 'u' stands for in 'elu_xxx'?
Daniel Juyung Seo (SeoZ)
On Thu, Oct 6, 2011 at 7:18 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Elementary support for EWS, with simplistic window manager.
This contains a very simple and stupid window manager to be used in
FB, PS3 or similar single-window engines. Everybody is welcome to
improve it, particularly:
* Edje: better border decoration theme
* Edje: nice background
* C + Edje: taskbar with minimized items.
* C + Edje: find a better protocol to determine window size,
accounting border decoration without account shadow! Right now I'm
taking everything :-P
* C: window management keys (Alt+F4 and like)
How to use: export ELM_ENGINE=ews
How to configure backing store: export
ECORE_EVAS_EWS=engine:x:y:w:h:options
Example:
{{{
export ECORE_EVAS_EWS=software_x11:0:0:1024:768
export ELM_ENGINE=ews
elementary_test
}}}
Bugs: maybe many, but so far seems it wouldn't take mouse events for
secondary windows. Will check it later.
Author: barbieri
Date: 2011-10-05 15:18:22 -0700 (Wed, 05 Oct 2011)
New Revision: 63849
Trac: http://trac.enlightenment.org/e/changeset/63849
Added:
trunk/elementary/data/themes/ews.edc
trunk/elementary/src/lib/elu_ews_wm.c
Modified:
trunk/elementary/data/themes/Makefile.am
trunk/elementary/data/themes/default.edc trunk/elementary/doc/widgets/
trunk/elementary/src/lib/Elementary.h.intrunk/elementary/src/lib/Makefile.am
trunk/elementary/src/lib/elm_config.c
trunk/elementary/src/lib/elm_main.c trunk/elementary/src/lib/elm_priv.h
trunk/elementary/src/lib/elm_theme.c trunk/elementary/src/lib/elm_win.c
trunk/elementary/src/modules/access_output/
trunk/elementary/src/modules/test_map/
Modified: trunk/elementary/data/themes/Makefile.am
===
--- trunk/elementary/data/themes/Makefile.am2011-10-05 22:11:00 UTC
(rev 63848)
+++ trunk/elementary/data/themes/Makefile.am2011-10-05 22:18:22 UTC
(rev 63849)
@@ -60,6 +60,7 @@
widgets/entry.edc \
widgets/map.edc \
widgets/scroller.edc \
+ews.edc \
arrow_down.png \
arrow_up.png \
bar_shine.png \
Modified: trunk/elementary/data/themes/default.edc
===
--- trunk/elementary/data/themes/default.edc2011-10-05 22:11:00 UTC
(rev 63848)
+++ trunk/elementary/data/themes/default.edc2011-10-05 22:18:22 UTC
(rev 63849)
@@ -365,4 +365,6 @@
#include widgets/video.edc
#include widgets/naviframe.edc
+#include ews.edc
+
}
Property changes on: trunk/elementary/doc/widgets
___
Modified: svn:ignore
- Makefile.in
Makefile
.deps
widget_preview_layout
widget_preview_colorselector
widget_preview_fileselector
widget_preview_ctxpopup
widget_preview_hover
widget_preview_anchorview
widget_preview_diskselector
widget_preview_separator
widget_preview_conformant
widget_preview_entry1
widget_preview_entry2
widget_preview_entry3
widget_preview_entry4
widget_preview_icon
widget_preview_clock
widget_preview_flipselector
widget_preview_list
widget_preview_button1
widget_preview_button2
widget_preview_button3
widget_preview_index
widget_preview_calendar
widget_preview_label
widget_preview_image
widget_preview_hoversel
widget_preview_bg
widget_preview_flip
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Lua2?
Talking to myself here. lol On Fri, 30 Sep 2011 11:15:54 +1000 David Seikel onef...@gmail.com wrote: I've restructured my edje so that there is a separate group with just embryo scripts in it. This group does not do any part manipulation, it just sends signals to the group with the parts. Next I can translate that group to a script only lua script. That will at least get me started with lua. Translated that to a lua script only block. It's half the size, and much easier to read. B-) /me wonders if Raster will pop his head in at some stage and give his thoughts about the current state of lua and his plans? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/elementary/src/lib
On Thu, 6 Oct 2011 17:37:25 -0700 Michael Jennings m...@kainx.org wrote: On Wednesday, 05 October 2011, at 16:43:03 (-0700), Enlightenment SVN wrote: - _elm_ews_wm_border_theme_set((void*)tp-key, tp-data, NULL); + _elm_ews_wm_border_theme_set(*(void**)tp-key, tp-data, NULL); http://c-faq.com/ptrs/genericpp.html Michael nice catch! -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas GL engine shader issue
Hi Folks,
With Evas trunk, I can no longer use the gl_x11 engine on my Intel 945GME.
I get the error message reproduced below.
Git bisect points to revision 63832. Any revision before that works fine.
Anyone else having this issue? I can supply more info if needed.
Thanks.
ERR1246:evas-gl_common evas_gl_shader.c:1082
_evas_gl_common_shader_program_source_init() Abort compile of shader vert
(nv12): #ifdef GL_ES
#ifdef GL_FRAGMENT_PRECISION_HIGH
precision highp float;
#else
precision mediump float;
#endif
#endif
attribute vec4 vertex;
attribute vec4 color;
attribute vec2 tex_coord, tex_coord2;
uniform mat4 mvp;
varying vec4 col;
varying vec2 tex_y, tex_cuv;
void main()
{
gl_Position = mvp * vertex;
col = color;
tex_y = tex_coord;
tex_cuv = tex_coord2 * 0.5;
}
Evas can not setup the informations of the OpenGL X11 Engine
No engine selected.
--
Jim Kukunas
Intel Open Source Technology Center
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas/Elm resolution management
On Wed, Oct 5, 2011 at 7:59 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Oct 5, 2011 at 6:41 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Tue, Oct 4, 2011 at 9:52 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Oct 3, 2011 at 11:06 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey Gustavo! Thanks for answering my email! It's appreciated. However it didn't answer my questions, because basically, no, I'm not going to implement a window manager for the PS3 :) Don't forget that all applications/games will be full screen windows, and that 0.1% of people (a lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so having multiple windows is not a solution. I'm ok with single window apps, and while I do want to have interoperability with existing EFL apps without (or few) modifications, I mostly want something for new app development and a clear API on how to change resolution and how to handle the situation I explained.. most importantly, I'm not going to implement a WM, compositor, wayland or anything fancy like that :) I am not focusing on multi window apps, in my previous email, when I said I used elementary_test, I failed to mention I only ran it with --test-win-only to make sure only one window is created, so this is not the issue here. You're overlooking the problem. :-) 1 - The game content itself will run on the main Ecore_Evas that uses PS3 directly, not the inner windows. Less overhead... And likely it will use the GL bindings, as most games will use GL directly and not Evas. Then, to configure the screen they would use this API to set their best resolution. Well, for new apps written for the ps3, I don't see a problem, you'd make sure you do everything right, use a single window, set the fullscreen flag, etc.. note, there is a check in elm_win.c that forces all FB windows in fullscreen, maybe you can add that to your as well. Yes, that's what i did originally, but this caused the elm_win_resize to not be called (see first email about that issue), that's why I was forced to remove that fullscreen flag. 2 - Most apps will need to have some kind of multiple windows, like popups and so to extend/configure the game. These will likely bring the need for this manager. Not really.. I don't expect to just run or port apps from the PC which use multiple windows.. on a TV it's just not doable.. don't forget that pretty much everyone will be controlling these with a ps3 controller and I don't see them switching from one window to another with that, it just doesn't feel right. If you look at eskiss, you'll see that's the kind of stuff I expect.. as for popup windows, or even contextual popup menus, (or menus), those shouldn't appear in a console app (but contextual popups still do work since they don't create a new window). I understand what you mean, but we're not talking about the same thing. Games will have to support specific bits for PS3, for instance they will have to know the mode they can achieve some FPS... In an ideal world it's not required, because API would abstract it... but in an ideal world the game would run well enough in all resolutions and this is not required as well :-) Yes, ps3 apps will have ps3 specific code, what my issue with screen res and fullscreen was, was that I didn't want to write a guide that says if you want to change resolution, you need to unset the fullscreen flag, resize the window, then set the fullscreen flag back. anyways if you're creating some kind of portal (eg: homebrew market), or using a browser (ie: ewebkit port) then you'll need multiple windows, or will have a huge work. Not really, a portal can work quite well with a single window, as for a browser, it's windows, yes, but you'd have a different way of accessing them.. the thing of having windows with decorations and using a mouse to move and 'focus' from one window to another is very desktop specific and not very joystick/joypad compatible. 3 - The manager should be simple. It's already possible right now, there is no hard code to do. You just manage windows as Evas_Object (Image) at the parent canvas, so window move = evas_object_move(window_backing_store, x, y). Resize, hide... are similar. Ecore provides such integration with ecore_evas_object_image_new(). What we need is to provide such engine for Elementary, instead of using your PS3 engine. I know it would be pretty simple in theory, but then you start doing it, then you need to add window decorations, then you test and a few use cases don't work, and you end up writing a lot of code instead of the simple couple of lines that you initially planned.. I also honestly don't see a point in doing that, at all, since multi-windowed application are absolutely not my target here. So
Re: [E-devel] Elm entry sizing issue
On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen t...@stosb.com wrote:
I'm away from home/computers until Saturday evening (leaving now), I'll
take a look at it soon after.
But I have a couple of questions until then:
What sizing do you get? what do you expect? The elm minimum height
should change according to the font size (unless it's smaller than the
finger size, which is then used).
It's taller than the part underneath it that it is set to be relative
to and smaller than. However, I'm betting that the finger size thing
is the issue here - any way to override/set the finger size
dynamically, to be able to get around that limitation in one-off
situations?
Thanks!
-James
--
Tom.
On 07/10/11 02:45, Ausmus, James wrote:
Hi All-
It appears that a standard Elementary entry widget has a minimum
height that it refuses to size beneath, regardless of the font size
being used, as demonstrated by the entry.c and entry.edc files below.
Is there any way around this? How can I get a short Elm entry that
actually obeys the size of the swallow - do I need to fully grok and
recreate the default Elm theme for an entry in order to reduce the min
height of it's visual components, or is there a (much) easier way? :)
Thanks!
-James
//
/*Begin entry.c */
#include stdio.h
#include Elementary.h
#include Edje.h
//UI signal callbacks
static Evas_Object *ly;
void main_quit_cb(void *data, Evas_Object *obj,
const char *emission, const char *source)
{
int x, y, h, w;
edje_object_part_geometry_get(elm_layout_edje_get(ly),
input_bg, x, y, w, h);
printf(after ibg geo: %i/%i, %i/%i\n, x, y, w, h);
edje_object_part_geometry_get(elm_layout_edje_get(ly),
input_swallow, x, y, w, h);
printf(after is geo: %i/%i, %i/%i\n, x, y, w, h);
elm_exit();
}
static Evas_Object* load_edj(Evas_Object *parent, const char *file,
const char *group)
{
Evas_Object *eo;
int r;
eo = elm_layout_add(parent);
if (eo) {
r = elm_layout_file_set(eo, file, group);
if (!r) {
evas_object_del(eo);
return NULL;
}
evas_object_size_hint_weight_set(eo,
EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
}
return eo;
}
int elm_main(int argc, char *argv[])
{
Evas_Object *win = NULL;
Evas_Object *tb;
int nw, nh;
/* create window */
win = elm_win_add(NULL, entry, ELM_WIN_BASIC);
if (win) {
elm_win_title_set(win, entry);
ecore_x_window_size_get(ecore_x_window_root_first_get(),
nw, nh);
evas_object_resize(win, nw, nh);
} else {
printf(couldn't create win!\n);
return -1;
}
/* load edje */
ly = load_edj(win, entry.edj, ui);
if (ly == NULL) {
printf(Couldn't create layout!\n);
return -1;
}
elm_win_resize_object_add(win, ly);
edje_object_signal_callback_add(elm_layout_edje_get(ly),
DONE_EXIT, *, main_quit_cb, NULL);
tb = elm_entry_add(ly);
if (tb) {
elm_entry_entry_set(tb, font size='4' color='white');
elm_entry_single_line_set(tb, EINA_TRUE);
elm_layout_content_set(ly, input_swallow, tb);
} else {
printf(Got null TB!\n);
return -1;
}
evas_object_show(ly);
evas_object_show(win);
elm_run();
elm_shutdown();
return 0;
}
ELM_MAIN();
/* End entry.c */
//
//
/* Begin entry.edc */
collections {
group {
name: ui;
parts {
part {
name: background;
type: RECT;
description {
state: default 0.0;
color: 0 0 0 100;
}
program {
name: background_clicked;
source: background;
signal: mouse,clicked,*;
action: SIGNAL_EMIT DONE_EXIT UI;
}
}
part {
name: input_bg;
Re: [E-devel] E SVN: bdilly trunk/ecore/src/lib/ecore
I recall this is Linux specific, If so add an ifdef
On Friday, October 7, 2011, Enlightenment SVN no-re...@enlightenment.org
wrote:
Log:
Ecore Exe: add flag to send SIGTERM when parent die
Add a new ecore exe flag, ECORE_EXE_TERM_WITH_PARENT,
that will operate on child process,
sending a SIGTERM when parent process dies.
Author: bdilly
Date: 2011-10-07 16:37:42 -0700 (Fri, 07 Oct 2011)
New Revision: 63915
Trac: http://trac.enlightenment.org/e/changeset/63915
Modified:
trunk/ecore/src/lib/ecore/Ecore.h trunk/ecore/src/lib/ecore/ecore_exe.c
Modified: trunk/ecore/src/lib/ecore/Ecore.h
===
--- trunk/ecore/src/lib/ecore/Ecore.h 2011-10-07 17:47:55 UTC (rev
63914)
+++ trunk/ecore/src/lib/ecore/Ecore.h 2011-10-07 23:37:42 UTC (rev
63915)
@@ -654,7 +654,8 @@
ECORE_EXE_PIPE_AUTO = 32, /** stdout and stderr are buffered
automatically */
ECORE_EXE_RESPAWN = 64, /** FIXME: Exe is restarted if it dies */
ECORE_EXE_USE_SH = 128, /** Use /bin/sh to run the command. */
-ECORE_EXE_NOT_LEADER = 256 /** Do not use setsid() to have the
executed process be its own session leader */
+ECORE_EXE_NOT_LEADER = 256, /** Do not use setsid() to have the
executed process be its own session leader */
+ECORE_EXE_TERM_WITH_PARENT = 512 /** Makes child receive SIGTERM
when parent dies. */
};
typedef enum _Ecore_Exe_Flags Ecore_Exe_Flags;
Modified: trunk/ecore/src/lib/ecore/ecore_exe.c
===
--- trunk/ecore/src/lib/ecore/ecore_exe.c 2011-10-07 17:47:55 UTC
(rev 63914)
+++ trunk/ecore/src/lib/ecore/ecore_exe.c 2011-10-07 23:37:42 UTC
(rev 63915)
@@ -14,6 +14,7 @@
#include sys/types.h
#include unistd.h
#include fcntl.h
+#include sys/prctl.h
#ifdef HAVE_SYS_WAIT_H
# include sys/wait.h
@@ -1509,6 +1510,11 @@
}
}
+ if ((flags ECORE_EXE_TERM_WITH_PARENT))
+ {
+prctl(PR_SET_PDEATHSIG, SIGTERM);
+ }
+
if (!(flags ECORE_EXE_NOT_LEADER)) setsid();
if ((flags ECORE_EXE_USE_SH))
{
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine shader issue
On Fri, Oct 7, 2011 at 10:40 PM, Jim Kukunas
james.t.kuku...@linux.intel.com wrote:
Hi Folks,
With Evas trunk, I can no longer use the gl_x11 engine on my Intel 945GME.
I get the error message reproduced below.
Git bisect points to revision 63832. Any revision before that works fine.
Anyone else having this issue? I can supply more info if needed.
Same issue here. looking at the output I would guess that the shader
file should be preprocessed before passing it to the shader compiler.
(I'm no expert in this)
Thanks.
ERR1246:evas-gl_common evas_gl_shader.c:1082
_evas_gl_common_shader_program_source_init() Abort compile of shader vert
(nv12): #ifdef GL_ES
#ifdef GL_FRAGMENT_PRECISION_HIGH
precision highp float;
#else
precision mediump float;
#endif
#endif
attribute vec4 vertex;
attribute vec4 color;
attribute vec2 tex_coord, tex_coord2;
uniform mat4 mvp;
varying vec4 col;
varying vec2 tex_y, tex_cuv;
void main()
{
gl_Position = mvp * vertex;
col = color;
tex_y = tex_coord;
tex_cuv = tex_coord2 * 0.5;
}
Evas can not setup the informations of the OpenGL X11 Engine
No engine selected.
--
Jim Kukunas
Intel Open Source Technology Center
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elm entry sizing issue
On Fri, 7 Oct 2011 14:16:58 -0700 Ausmus, James james.aus...@intel.com said:
On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen t...@stosb.com wrote:
I'm away from home/computers until Saturday evening (leaving now), I'll
take a look at it soon after.
But I have a couple of questions until then:
What sizing do you get? what do you expect? The elm minimum height
should change according to the font size (unless it's smaller than the
finger size, which is then used).
It's taller than the part underneath it that it is set to be relative
to and smaller than. However, I'm betting that the finger size thing
is the issue here - any way to override/set the finger size
dynamically, to be able to get around that limitation in one-off
situations?
use a label then, not entry. an entry is there for the purpose of entering
text or selecting it etc. - not just display. thus it forces it to be at least
a finger size in height for single line entries (for multiple line its a bit
nastier so it doesn't currently). the whole point of finger size it to ensure a
person can reliably press on it. if you have a desktop app finger size should
be globally on your system set to something low - like 5. so you wont have a
problem. but elm is fixing the ui to make it usable for people. you don't need
your ui test department now to tell you to fix it anymore. :)
Thanks!
-James
--
Tom.
On 07/10/11 02:45, Ausmus, James wrote:
Hi All-
It appears that a standard Elementary entry widget has a minimum
height that it refuses to size beneath, regardless of the font size
being used, as demonstrated by the entry.c and entry.edc files below.
Is there any way around this? How can I get a short Elm entry that
actually obeys the size of the swallow - do I need to fully grok and
recreate the default Elm theme for an entry in order to reduce the min
height of it's visual components, or is there a (much) easier way? :)
Thanks!
-James
//
/*Begin entry.c */
#include stdio.h
#include Elementary.h
#include Edje.h
//UI signal callbacks
static Evas_Object *ly;
void main_quit_cb(void *data, Evas_Object *obj,
const char *emission, const char *source)
{
int x, y, h, w;
edje_object_part_geometry_get(elm_layout_edje_get(ly),
input_bg, x, y, w, h);
printf(after ibg geo: %i/%i, %i/%i\n, x, y, w, h);
edje_object_part_geometry_get(elm_layout_edje_get(ly),
input_swallow, x, y, w, h);
printf(after is geo: %i/%i, %i/%i\n, x, y, w, h);
elm_exit();
}
static Evas_Object* load_edj(Evas_Object *parent, const char *file,
const char *group)
{
Evas_Object *eo;
int r;
eo = elm_layout_add(parent);
if (eo) {
r = elm_layout_file_set(eo, file, group);
if (!r) {
evas_object_del(eo);
return NULL;
}
evas_object_size_hint_weight_set(eo,
EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
}
return eo;
}
int elm_main(int argc, char *argv[])
{
Evas_Object *win = NULL;
Evas_Object *tb;
int nw, nh;
/* create window */
win = elm_win_add(NULL, entry, ELM_WIN_BASIC);
if (win) {
elm_win_title_set(win, entry);
ecore_x_window_size_get(ecore_x_window_root_first_get(),
nw, nh);
evas_object_resize(win, nw, nh);
} else {
printf(couldn't create win!\n);
return -1;
}
/* load edje */
ly = load_edj(win, entry.edj, ui);
if (ly == NULL) {
printf(Couldn't create layout!\n);
return -1;
}
elm_win_resize_object_add(win, ly);
edje_object_signal_callback_add(elm_layout_edje_get(ly),
DONE_EXIT, *, main_quit_cb, NULL);
tb = elm_entry_add(ly);
if (tb) {
elm_entry_entry_set(tb, font size='4' color='white');
elm_entry_single_line_set(tb, EINA_TRUE);
elm_layout_content_set(ly, input_swallow, tb);
} else {
printf(Got null TB!\n);
return -1;
}
evas_object_show(ly);
evas_object_show(win);
elm_run();
elm_shutdown();
return 0;
}
ELM_MAIN();
/* End entry.c */
//
//
/* Begin entry.edc */
collections {
group {
name: ui;
Re: [E-devel] Evas GL engine shader issue
On Fri, 7 Oct 2011 13:40:35 -0700 Jim Kukunas james.t.kuku...@linux.intel.com
said:
evas does have code to get the actual compile error in gl_compile_link_error()
- but your mail doesn't paste any of that. it should be right above what you
pasted if the glsl compiler is reporting errors in error logs. (it also would
have complained about fragment compile error too before that).
Hi Folks,
With Evas trunk, I can no longer use the gl_x11 engine on my Intel 945GME.
I get the error message reproduced below.
Git bisect points to revision 63832. Any revision before that works fine.
Anyone else having this issue? I can supply more info if needed.
Thanks.
ERR1246:evas-gl_common evas_gl_shader.c:1082
_evas_gl_common_shader_program_source_init() Abort compile of shader vert
(nv12): #ifdef GL_ES
#ifdef GL_FRAGMENT_PRECISION_HIGH
precision highp float;
#else
precision mediump float;
#endif
#endif
attribute vec4 vertex;
attribute vec4 color;
attribute vec2 tex_coord, tex_coord2;
uniform mat4 mvp;
varying vec4 col;
varying vec2 tex_y, tex_cuv;
void main()
{
gl_Position = mvp * vertex;
col = color;
tex_y = tex_coord;
tex_cuv = tex_coord2 * 0.5;
}
Evas can not setup the informations of the OpenGL X11 Engine
No engine selected.
--
Jim Kukunas
Intel Open Source Technology Center
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
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)ras...@rasterman.com
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine shader issue
On Sat, 8 Oct 2011 04:32:22 +0200 hannes.janet...@gmail.com
hannes.janet...@googlemail.com said:
On Fri, Oct 7, 2011 at 10:40 PM, Jim Kukunas
james.t.kuku...@linux.intel.com wrote:
Hi Folks,
With Evas trunk, I can no longer use the gl_x11 engine on my Intel 945GME.
I get the error message reproduced below.
Git bisect points to revision 63832. Any revision before that works fine.
Anyone else having this issue? I can supply more info if needed.
Same issue here. looking at the output I would guess that the shader
file should be preprocessed before passing it to the shader compiler.
(I'm no expert in this)
no - thats the glsls compilers job. those pre-processing things rely on
defined constants from the compiler. it's how glsl works. i found it by manual
inspection and comparison. cedric uses tex_y in vert shdr but tex_c in frag
shader. fixed.
Thanks.
ERR1246:evas-gl_common evas_gl_shader.c:1082
_evas_gl_common_shader_program_source_init() Abort compile of shader vert
(nv12): #ifdef GL_ES
#ifdef GL_FRAGMENT_PRECISION_HIGH
precision highp float;
#else
precision mediump float;
#endif
#endif
attribute vec4 vertex;
attribute vec4 color;
attribute vec2 tex_coord, tex_coord2;
uniform mat4 mvp;
varying vec4 col;
varying vec2 tex_y, tex_cuv;
void main()
{
gl_Position = mvp * vertex;
col = color;
tex_y = tex_coord;
tex_cuv = tex_coord2 * 0.5;
}
Evas can not setup the informations of the OpenGL X11 Engine
No engine selected.
--
Jim Kukunas
Intel Open Source Technology Center
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
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)ras...@rasterman.com
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine shader issue
On Sat, 8 Oct 2011 12:06:42 +0900
Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:
On Sat, 8 Oct 2011 04:32:22 +0200 hannes.janet...@gmail.com
hannes.janet...@googlemail.com said:
On Fri, Oct 7, 2011 at 10:40 PM, Jim Kukunas
james.t.kuku...@linux.intel.com wrote:
Hi Folks,
With Evas trunk, I can no longer use the gl_x11 engine on my Intel 945GME.
I get the error message reproduced below.
Git bisect points to revision 63832. Any revision before that works fine.
Anyone else having this issue? I can supply more info if needed.
Same issue here. looking at the output I would guess that the shader
file should be preprocessed before passing it to the shader compiler.
(I'm no expert in this)
no - thats the glsls compilers job. those pre-processing things rely on
defined constants from the compiler. it's how glsl works. i found it by manual
inspection and comparison. cedric uses tex_y in vert shdr but tex_c in frag
shader. fixed.
Thanks.
ERR1246:evas-gl_common evas_gl_shader.c:1082
_evas_gl_common_shader_program_source_init() Abort compile of shader vert
(nv12): #ifdef GL_ES
#ifdef GL_FRAGMENT_PRECISION_HIGH
precision highp float;
#else
precision mediump float;
#endif
#endif
attribute vec4 vertex;
attribute vec4 color;
attribute vec2 tex_coord, tex_coord2;
uniform mat4 mvp;
varying vec4 col;
varying vec2 tex_y, tex_cuv;
void main()
{
gl_Position = mvp * vertex;
col = color;
tex_y = tex_coord;
tex_cuv = tex_coord2 * 0.5;
}
Evas can not setup the informations of the OpenGL X11 Engine
No engine selected.
--
Jim Kukunas
Intel Open Source Technology Center
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
another bug found and fixed with svn log | grep cedric !
--
Mike Blumenkrantz
Zentific: Coding in binary since '10.
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
