Re: [E-devel] [PATCH] fix build warning in scim-immodule
On Tue, Dec 27, 2011 at 3:13 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/12/27 Jihoon Kim imfin...@gmail.com: Here are two simple patches. 'fix_warning_scim_imcontext.patch' is for fixing build warning 'warning: unused parameter' in scim-immodule. 'fix_indent_Makefile.patch' is for fixing indentation of Makefile.am in immodules/scim directory. Would you please apply in svn? In, both at once. I changed the warning fix to include config.h at the top, as that's what we do everywhere else. I'm also wondering if your next patch shouldn't be an info.txt file and your public key. Sounds like a lazy way to get the work done faster and better as Jihoon has been annoyingly sending patch that get in svn quite fast since sometimes now. So I vote that we get less work and put the burden on him by giving him svn access. -- Cedric BAIL -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] fix build warning in scim-immodule
2011/12/27 Jihoon Kim imfin...@gmail.com: Hi, Here are two simple patches. 'fix_warning_scim_imcontext.patch' is for fixing build warning 'warning: unused parameter' in scim-immodule. 'fix_indent_Makefile.patch' is for fixing indentation of Makefile.am in immodules/scim directory. Would you please apply in svn? In, both at once. I changed the warning fix to include config.h at the top, as that's what we do everywhere else. I'm also wondering if your next patch shouldn't be an info.txt file and your public key. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [patch] elm_cnp_helper - change elm_cnp_selection_set and code cleanup
Dear all.
As discomfitor suggested, I cleanup some codes.
elm_cnp_selection_set : add buffer length argument and check for image type.
(i think it's urgent issue before elm_cnp_selection_set api is widely used.)
enum defines : add 'type' prefix.
Thanks
Index: elementary/src/lib/elm_entry.c
===
--- elementary/src/lib/elm_entry.c (리비전 66563)
+++ elementary/src/lib/elm_entry.c (작업 사본)
@@ -1121,12 +1121,12 @@
if (wd-sel_notify_handler)
{
#ifdef HAVE_ELEMENTARY_X
-Elm_Sel_Format formats;
+Elm_Sel_Format_Type formats;
wd-selection_asked = EINA_TRUE;
-formats = ELM_SEL_FORMAT_MARKUP;
+formats = ELM_SEL_FORMAT_TYPE_MARKUP;
if (!wd-textonly)
- formats |= ELM_SEL_FORMAT_IMAGE;
-elm_cnp_selection_get(ELM_SEL_CLIPBOARD, formats, data, NULL, NULL);
+ formats |= ELM_SEL_FORMAT_TYPE_IMAGE;
+elm_cnp_selection_get(ELM_SEL_TYPE_CLIPBOARD, formats, data, NULL,
NULL);
#endif
}
}
@@ -1140,8 +1140,8 @@
if (!wd) return;
sel = edje_object_part_text_selection_get(wd-ent, elm.text);
if ((!sel) || (!sel[0])) return; /* avoid deleting our own selection */
- elm_cnp_selection_set(seltype, obj, ELM_SEL_FORMAT_MARKUP, sel);
- if (seltype == ELM_SEL_CLIPBOARD)
+ elm_cnp_selection_set(seltype, obj, ELM_SEL_FORMAT_TYPE_MARKUP, sel,
strlen(sel));
+ if (seltype == ELM_SEL_TYPE_CLIPBOARD)
eina_stringshare_replace(wd-cut_sel, sel);
}
@@ -1157,7 +1157,7 @@
edje_object_signal_emit(wd-ent, elm,state,select,off, elm);
if (!_elm_config-desktop_entry)
elm_widget_scroll_hold_pop(data);
- _store_selection(ELM_SEL_CLIPBOARD, data);
+ _store_selection(ELM_SEL_TYPE_CLIPBOARD, data);
edje_object_part_text_insert(wd-ent, elm.text, );
edje_object_part_text_select_none(wd-ent, elm.text);
_sizing_eval(data);
@@ -1175,7 +1175,7 @@
edje_object_signal_emit(wd-ent, elm,state,select,off, elm);
elm_widget_scroll_hold_pop(data);
}
- _store_selection(ELM_SEL_CLIPBOARD, data);
+ _store_selection(ELM_SEL_TYPE_CLIPBOARD, data);
// edje_object_part_text_select_none(wd-ent, elm.text);
}
@@ -1531,7 +1531,8 @@
top = elm_widget_top_get(data);
if ((top) (elm_win_xwindow_get(top)))
- elm_cnp_selection_set(ELM_SEL_PRIMARY, data, ELM_SEL_FORMAT_MARKUP,
txt);
+ elm_cnp_selection_set(ELM_SEL_TYPE_PRIMARY, data,
+ELM_SEL_FORMAT_TYPE_MARKUP, txt, strlen(txt));
}
#endif
}
@@ -1559,7 +1560,7 @@
if (!wd) return;
wd-have_selection = EINA_TRUE;
evas_object_smart_callback_call(data, SIG_SELECTION_CHANGED, NULL);
- _store_selection(ELM_SEL_PRIMARY, data);
+ _store_selection(ELM_SEL_TYPE_PRIMARY, data);
}
static void
@@ -1579,8 +1580,9 @@
top = elm_widget_top_get(data);
if ((top) (elm_win_xwindow_get(top)))
- elm_cnp_selection_set(ELM_SEL_PRIMARY, data,
ELM_SEL_FORMAT_MARKUP,
- wd-cut_sel);
+ elm_cnp_selection_set(ELM_SEL_TYPE_PRIMARY, data,
+ ELM_SEL_FORMAT_TYPE_MARKUP, wd-cut_sel,
+ strlen(wd-cut_sel));
#endif
eina_stringshare_del(wd-cut_sel);
wd-cut_sel = NULL;
@@ -1592,7 +1594,7 @@
top = elm_widget_top_get(data);
if ((top) (elm_win_xwindow_get(top)))
- elm_cnp_selection_clear(ELM_SEL_PRIMARY, data);
+ elm_cnp_selection_clear(ELM_SEL_TYPE_PRIMARY, data);
#endif
}
}
@@ -1602,7 +1604,8 @@
_signal_entry_paste_request(void *data, Evas_Object *obj __UNUSED__, const
char *emission, const char *source __UNUSED__)
{
Widget_Data *wd = elm_widget_data_get(data);
- Elm_Sel_Type type = (emission[sizeof(ntry,paste,request,)] == '1') ?
ELM_SEL_PRIMARY : ELM_SEL_CLIPBOARD;
+ Elm_Sel_Type type = (emission[sizeof(ntry,paste,request,)] == '1') ?
+ ELM_SEL_TYPE_PRIMARY : ELM_SEL_TYPE_CLIPBOARD;
if (!wd) return;
evas_object_smart_callback_call(data, SIG_SELECTION_PASTE, NULL);
if (wd-sel_notify_handler)
@@ -1614,7 +1617,7 @@
if ((top) (elm_win_xwindow_get(top)))
{
wd-selection_asked = EINA_TRUE;
- elm_cnp_selection_get(type, ELM_SEL_FORMAT_MARKUP, data,
+ elm_cnp_selection_get(type, ELM_SEL_FORMAT_TYPE_MARKUP, data,
NULL, NULL);
}
#endif
@@ -2346,7 +2349,7 @@
_event_selection_clear, obj);
}
- elm_drop_target_add(obj, ELM_SEL_FORMAT_MARKUP | ELM_SEL_FORMAT_IMAGE,
+ elm_drop_target_add(obj, ELM_SEL_FORMAT_TYPE_MARKUP |
ELM_SEL_FORMAT_TYPE_IMAGE,
_drag_drop_cb, NULL);
#endif
@@ -2441,7 +2444,7 @@
else
{
#ifdef HAVE_ELEMENTARY_X
-elm_drop_target_add(obj,
Re: [E-devel] [patch] elm_cnp_helper - change elm_cnp_selection_set and code cleanup
On Tue, 27 Dec 2011 20:15:14 +0900 Hyoyoung Chang hyoyo...@gmail.com wrote: Dear all. As discomfitor suggested, I cleanup some codes. elm_cnp_selection_set : add buffer length argument and check for image type. (i think it's urgent issue before elm_cnp_selection_set api is widely used.) enum defines : add 'type' prefix. Thanks in, but you misunderstood what I was saying about namespacing. I didn't mean that everything has to include TYPE, I meant that enum values need to include the full name of the enum. I made the following changes: sed -i 's/ELM_SEL_FORMAT_TYPE/ELM_SEL_FORMAT/g' sed -i 's/Elm_Sel_Format_Type/Elm_Sel_Format/g' -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch] elc_ctxpopup, using elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
Dear All, Hello~
The ctxpopup had used elm_ojbect_scroll_freeze_push(), pop() for the
scroll-freeze-on,of callback.
If user calls elm_object_scroll_freeze_pop() only after
elm_ojbect_scroll_freeze_push(), then it will be fine.
But sometimes user calls elm_object_scroll_freeze_pop() two times in a
row.. Then you can find there is infinite loop in following..
EAPI void
elm_widget_scroll_freeze_pop(Evas_Object *obj)
{
API_ENTRY return;
sd-scroll_freeze--;
if (sd-scroll_freeze 0) sd-scroll_freeze = 0;
if (!sd-scroll_freeze)
evas_object_smart_callback_call(obj, scroll-freeze-off, obj);
if (sd-parent_obj) elm_widget_scroll_freeze_pop(sd-parent_obj);
}
ctxpopup calls elm_widget_scroll_freeze_pop(wd-scr);finally. wd-scr
is widget data of ctxpopup.
Now the the sd-parent_obj is ctxpopup, next time
evas_object_smart_callback_call(obj, scroll-freeze-off, obj); is
called again by using ctxpopup as obj.
Anyhow, other widgets..
the ctxpopup should use elm_smart_scroller_freeze_set() with an attached patch.
Sincerely,
Shinwoo Kim.
Index: src/lib/elc_ctxpopup.c
===
--- src/lib/elc_ctxpopup.c (revision 66566)
+++ src/lib/elc_ctxpopup.c (working copy)
@@ -148,7 +148,7 @@
Widget_Data *wd = elm_widget_data_get(obj);
if ((!wd) || (!wd-scr)) return;
- elm_object_scroll_freeze_push(wd-scr);
+ elm_smart_scroller_freeze_set(wd-scr, EINA_TRUE);
}
static void
@@ -158,7 +158,7 @@
Widget_Data *wd = elm_widget_data_get(obj);
if ((!wd) || (!wd-scr)) return;
- elm_object_scroll_freeze_pop(wd-scr);
+ elm_smart_scroller_freeze_set(wd-scr, EINA_FALSE);
}
static void
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch] elm_conform patch
Hi, Attachment to the mail is elm_conform patch. Change Description: When no geometry information of ind/sft/kbd, resetting the geometry. Thanks, Prince elm_conform.patch Description: Binary data -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: leif trunk/e/src/bin
I learned how to record the gdb session. The attached gdb sessions may provide more useful information. One gdb session run as root, the other as user. Ran to break, then stepped through. Hope this helps. mike GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/enlightenment...done. (gdb) br _e_randr_crtc_info_set Breakpoint 1 at 0x4fc72b: file e_randr.c, line 546. (gdb) r Starting program: /usr/local/bin/enlightenment [Thread debugging using libthread_db enabled] ESTART: 0.0 [0.0] - Begin Startup ESTART: 0.00010 [0.00010] - Signal Trap ESTART: 0.00012 [0.3] - Signal Trap Done ESTART: 0.01462 [0.01449] - Eina Init ESTART: 0.01516 [0.00054] - Eina Init Done ESTART: 0.01517 [0.1] - Determine Prefix = Enlightenment relocation handling = PREFIX: /usr/local BINDIR: /usr/local/bin LIBDIR: /usr/local/lib DATADIR: /usr/local/share/enlightenment LOCALE: /usr/local/share/locale = ESTART: 0.05223 [0.03707] - Determine Prefix Done ESTART: 0.05231 [0.8] - Environment Variables ESTART: 0.05235 [0.4] - Environment Variables Done ESTART: 0.05236 [0.1] - Parse Arguments ESTART: 0.05238 [0.3] - Parse Arguments Done ESTART: 0.05239 [0.1] - Eet Init ESTART: 0.05695 [0.00456] - Eet Init Done ESTART: 0.05699 [0.4] - Ecore Init ESTART: 0.05748 [0.00049] - Ecore Init Done ESTART: 0.05751 [0.3] - Ecore Event Handlers ESTART: 0.05752 [0.2] - Ecore Event Handlers Done ESTART: 0.05753 [0.1] - Ecore_IMF Init ESTART: 0.14440 [0.08687] - Ecore_IMF Init Done ESTART: 0.1 [0.4] - Ecore_File Init ESTART: 0.14498 [0.00054] - Ecore_File Init Done ESTART: 0.14500 [0.2] - Ecore_Con Init ESTART: 0.14517 [0.00017] - Ecore_Con Init Done ESTART: 0.14518 [0.1] - Ecore_Ipc Init ESTART: 0.14520 [0.2] - Ecore_Ipc Init Done ESTART: 0.14522 [0.2] - Ecore_X Init ESTART: 0.14523 [0.1] - Ecore_X Init Done ESTART: 0.14524 [0.1] - Ecore_Evas Init ESTART: 0.18133 [0.03609] - Ecore_Evas Init Done ESTART: 0.18137 [0.4] - Ecore_Evas Engine Check ESTART: 0.18138 [0.1] - Ecore_Evas Engine Check Done ESTART: 0.18139 [0.1] - Edje Init ESTART: 0.20255 [0.02116] - Edje Init Done ESTART: 0.20260 [0.5] - E Intl Init ESTART: 0.21375 [0.01116] - E Intl Init Done ESTART: 0.21379 [0.4] - E_Alert Init ESTART: 0.21380 [0.1] - E_Alert Init Done ESTART: 0.21381 [0.1] - E_Xinerama Init E17 INIT: XINERAMA SCREEN: [0], 1920x1080+0+0 E17 INIT: XINERAMA CHOSEN: [0], 1920x1080+0+0 ESTART: 0.21568 [0.00187] - E_Xinerama Init Done ESTART: 0.21570 [0.2] - E_Hints Init ESTART: 0.21749 [0.00179] - E_Hints Init Done ESTART: 0.21751 [0.3] - E_Configure Init ESTART: 0.21766 [0.00015] - E_Configure Init Done ESTART: 0.21767 [0.1] - E Directories Init ESTART: 0.24693 [0.02926] - E Directories Init Done ESTART: 0.24697 [0.4] - E_Filereg Init ESTART: 0.24782 [0.00085] - E_Filereg Init Done ESTART: 0.24785 [0.3] - E_Config Init ESTART: 0.27811 [0.03026] - E_Config Init Done ESTART: 0.27844 [0.00033] - E_Randr Init E_RANDR: filling 1/6 (79) Breakpoint 1, _e_randr_crtc_info_set (crtc_info=0x7f8540) at e_randr.c:546 546Ecore_X_Randr_Mode mode = 0; (gdb) step 547fprintf(stderr, Fillng CRTC %d (%p)\n, crtc_info-xid, crtc_info); (gdb) step Fillng CRTC 79 (0x7f8540) 548if (E_RANDR_NO_12 || !crtc_info) return; (gdb) step 551_e_randr_crtc_outputs_refs_update(crtc_info); (gdb) step _e_randr_crtc_outputs_refs_update (crtc_info=0x7f8540) at e_randr.c:1915 1915 if (!e_randr_screen_info-rrvd_info.randr_info_12-outputs) return; (gdb) step 1918 if ((outputs = ecore_x_randr_crtc_outputs_get(e_randr_screen_info-root, crtc_info-xid, noutputs))) (gdb) step ecore_x_randr_crtc_outputs_get (root=363, crtc=79, num=0x7fffd9c4) at ecore_x_randr_12.c:536 536RANDR_CHECK_1_2_RET(NULL); (gdb) step 537XRRScreenResources *res = NULL; (gdb) step 538Ecore_X_Randr_Output *ret = NULL; (gdb) step 539XRRCrtcInfo *crtc_info = NULL; (gdb) step 541if (_ecore_x_randr_crtc_validate(root, (gdb) step _ecore_x_randr_crtc_validate (root=363, crtc=79) at ecore_x_randr_12.c:85 85 RANDR_CHECK_1_2_RET(EINA_FALSE); (gdb) step 87 XRRScreenResources *res = NULL; (gdb) step 89 Eina_Bool ret = EINA_FALSE; (gdb) step 91 if ((crtc == Ecore_X_Randr_None) || (gdb) step 95 if (_ecore_x_randr_root_validate(root) crtc (gdb) step _ecore_x_randr_root_validate
Re: [E-devel] on whitespaces
On Mon, Dec 26, 2011 at 5:56 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Dec 26, 2011 at 8:53 PM, Christopher Michael
cpmicha...@comcast.net wrote:
On 12/26/11 05:22, Michael Blumenkrantz wrote:
On Mon, 26 Dec 2011 03:27:17 -0500
Christopher Michaelcpmicha...@comcast.net wrote:
On 12/26/11 00:17, Michael Blumenkrantz wrote:
can we have a rule that there will be ZERO whitespace-related commits from
now on?
Good luck with that :P It's just something that DOES happen...if on
purpose (or not), it still Does happen. Have to deal w/ it. After 10-15
years of trying to keep EFL formatting, I've given up ;)
it clutters up the log and serves no purpose. if we want to be really
particular about it,
Well, if that WAS the case then We'd still be in the stone ages wrt
efl/e cause MANY (if not all) patches that come across are Never
formated as per E/EFL rules. People just don't follow what's been
established :( (they'd rather code to their own rules, and that's a
pretty much given truth)
we should just have a single commit to do this just before
a release.
Well, THAT, or just ignore whitespace in patches. IE: If a patch
includes a good fix, then go for it. If same patch ALso includes
formatting fixes, then accept it and fix the whitespace issues later.
If said patch fixes a real bug, accept it. The formatting can be fixed
later.
Whitespace (in and of itself) is not that big a deal (unless the
formatting is terribly wrong in which case, we tell the patcher to @
least try to adhere.) and can be easily ignored (if patch reviewer
just looks @ the code itself). The only thing unacceptable (imo) is all
this wasted whitespace wrt trying to align variables. We all know what
I am talking about:
Evas_Object *myobj;
Evas *myevas;
Is Easier to read (cause human brain normally goes left to right), Than:
Evas_Object *myobh
Evas *myevas
Now, I have to read hey, there's an Evas ... let me page over and see
what the variable name is ... UUGGG What a waste (of time AND
whitespace)...
Having said that:
If the fix is good, then the formatting can be fixed later...just my
2 cents
dh
well, I was mainly talking about trailing whitespaces (which are not
formatting-related). I suppose I should have specified. I do agree with your
points, however.
Ahhh, Trailing whitespaces...I see. Yea, those can be annoying, but
sometimes they are not avoidable. I know that code I write sometimes
has them, but it's normally the 'editor' which is doing it. Ie, if I
write a line:
if (variable) {
then while writing it, when I get to the bracket my editor automatically
puts the bracket on the next line (with the proper indented space for
efl formatting) and what gets left is what looks like a 'trailing'
whitespace.
Mine do remove the trailing whitespace in that case...
And an easier solution is to simply highlight them...
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore_Evas (Wayland_Shm):
Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame
w/ the title).
Couldn't you reuse in some way what Gustavo did in the EWL backend ?
Add support for size_min/max/base/step setting.
Add support for title name_class setting.
Add support for setting a cursor.
Add support for hiding an ecore_evas.
Author: devilhorns
Date: 2011-12-27 11:25:38 -0800 (Tue, 27 Dec 2011)
New Revision: 66578
Trac: http://trac.enlightenment.org/e/changeset/66578
Modified:
trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c
Modified: trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c
===
--- trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c 2011-12-27
19:12:56 UTC (rev 66577)
+++ trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c 2011-12-27
19:25:38 UTC (rev 66578)
@@ -31,6 +31,15 @@
# include Evas_Engine_Wayland_Shm.h
# include Ecore_Wayland.h
+/* local structures */
+typedef struct _EE_Wl_Smart_Data EE_Wl_Smart_Data;
+struct _EE_Wl_Smart_Data
+{
+ Evas_Object *frame;
+ Evas_Object *text;
+ Evas_Coord x, y, w, h;
+};
+
/* local function prototypes */
static int _ecore_evas_wl_init(void);
static int _ecore_evas_wl_shutdown(void);
@@ -43,6 +52,15 @@
static void _ecore_evas_wl_callback_focus_out_set(Ecore_Evas *ee, void
(*func)(Ecore_Evas *ee));
static void _ecore_evas_wl_resize(Ecore_Evas *ee, int w, int h);
static void _ecore_evas_wl_show(Ecore_Evas *ee);
+static void _ecore_evas_wl_hide(Ecore_Evas *ee);
+static void _ecore_evas_wl_title_set(Ecore_Evas *ee, const char *t);
+static void _ecore_evas_wl_name_class_set(Ecore_Evas *ee, const char *n,
const char *c);
+static void _ecore_evas_wl_size_min_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_max_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_base_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_step_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_object_cursor_set(Ecore_Evas *ee, Evas_Object
*obj, int layer, int hot_x, int hot_y);
+static void _ecore_evas_wl_object_cursor_del(void *data, Evas *evas
__UNUSED__, Evas_Object *obj __UNUSED__, void *event __UNUSED__);
static int _ecore_evas_wl_render(Ecore_Evas *ee);
static void _ecore_evas_wl_screen_geometry_get(const Ecore_Evas *ee
__UNUSED__, int *x, int *y, int *w, int *h);
static void _ecore_evas_wl_buffer_new(Ecore_Evas *ee, void **dest);
@@ -56,6 +74,18 @@
static Eina_Bool _ecore_evas_wl_event_focus_in(void *data __UNUSED__, int
type __UNUSED__, void *event);
static Eina_Bool _ecore_evas_wl_event_focus_out(void *data __UNUSED__, int
type __UNUSED__, void *event);
+/* SMART stuff for frame */
+static Evas_Smart *_ecore_evas_wl_smart = NULL;
+
+static void _ecore_evas_wl_smart_init(void);
+static void _ecore_evas_wl_smart_add(Evas_Object *obj);
+static void _ecore_evas_wl_smart_del(Evas_Object *obj);
+static void _ecore_evas_wl_smart_resize(Evas_Object *obj, Evas_Coord w,
Evas_Coord h);
+static void _ecore_evas_wl_smart_show(Evas_Object *obj);
+static void _ecore_evas_wl_smart_hide(Evas_Object *obj);
+
+static Evas_Object *_ecore_evas_wl_frame_add(Evas *evas);
+
/* local variables */
static int _ecore_evas_wl_init_count = 0;
static Ecore_Event_Handler *_ecore_evas_wl_event_handlers[8];
@@ -84,17 +114,17 @@
NULL, // func rotation set
NULL, // func shaped set
_ecore_evas_wl_show,
- NULL, // func hide
+ _ecore_evas_wl_hide,
NULL, // func raise
NULL, // func lower
NULL, // func activate
- NULL, // func title set
- NULL, // func name_class set
- NULL, // func size min set
- NULL, // func size max set
- NULL, // func size base set
- NULL, // func size step set
- NULL, // func object cursor set
+ _ecore_evas_wl_title_set,
+ _ecore_evas_wl_name_class_set,
+ _ecore_evas_wl_size_min_set,
+ _ecore_evas_wl_size_max_set,
+ _ecore_evas_wl_size_base_set,
+ _ecore_evas_wl_size_step_set,
+ _ecore_evas_wl_object_cursor_set,
NULL, // func layer set
NULL, // func focus set
NULL, // func iconified set
@@ -200,6 +230,13 @@
* engine destination */
ecore_evas_callback_pre_free_set(ee, _ecore_evas_wl_pre_free);
+ if (ee-prop.draw_frame)
+ {
+ ee-engine.wl.frame = _ecore_evas_wl_frame_add(ee-evas);
+ evas_object_is_frame_object_set(ee-engine.wl.frame, EINA_TRUE);
+ evas_object_move(ee-engine.wl.frame, 0, 0);
+ }
+
ecore_evas_input_event_register(ee);
_ecore_evas_register(ee);
@@ -281,6 +318,9 @@
LOGFN(__FILE__, __LINE__, __FUNCTION__);
+ /* destroy frame */
+ if (ee-engine.wl.frame) evas_object_del(ee-engine.wl.frame);
+
/* get engine info */
Re: [E-devel] [PATCH] fix build warning in scim-immodule
+1 here. He's been sending many patches so far and done a good job mainly on ecore imf. Daniel Juyung Seo (SeoZ) On Tue, Dec 27, 2011 at 11:28 PM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Dec 27, 2011 at 3:13 PM, Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/12/27 Jihoon Kim imfin...@gmail.com: Here are two simple patches. 'fix_warning_scim_imcontext.patch' is for fixing build warning 'warning: unused parameter' in scim-immodule. 'fix_indent_Makefile.patch' is for fixing indentation of Makefile.am in immodules/scim directory. Would you please apply in svn? In, both at once. I changed the warning fix to include config.h at the top, as that's what we do everywhere else. I'm also wondering if your next patch shouldn't be an info.txt file and your public key. Sounds like a lazy way to get the work done faster and better as Jihoon has been annoyingly sending patch that get in svn quite fast since sometimes now. So I vote that we get less work and put the burden on him by giving him svn access. -- Cedric BAIL -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] on whitespaces
There were a couple of discussions before on this topic.
I gave up removing trailing white spaces because they're out of
concern for the most e-devs.
And even committers are continuously pushing them in.
Daniel Juyung Seo (SeoZ)
On Wed, Dec 28, 2011 at 3:10 AM, Rafael Antognolli
antogno...@profusion.mobi wrote:
On Mon, Dec 26, 2011 at 5:56 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Dec 26, 2011 at 8:53 PM, Christopher Michael
cpmicha...@comcast.net wrote:
On 12/26/11 05:22, Michael Blumenkrantz wrote:
On Mon, 26 Dec 2011 03:27:17 -0500
Christopher Michaelcpmicha...@comcast.net wrote:
On 12/26/11 00:17, Michael Blumenkrantz wrote:
can we have a rule that there will be ZERO whitespace-related commits
from
now on?
Good luck with that :P It's just something that DOES happen...if on
purpose (or not), it still Does happen. Have to deal w/ it. After 10-15
years of trying to keep EFL formatting, I've given up ;)
it clutters up the log and serves no purpose. if we want to be really
particular about it,
Well, if that WAS the case then We'd still be in the stone ages wrt
efl/e cause MANY (if not all) patches that come across are Never
formated as per E/EFL rules. People just don't follow what's been
established :( (they'd rather code to their own rules, and that's a
pretty much given truth)
we should just have a single commit to do this just before
a release.
Well, THAT, or just ignore whitespace in patches. IE: If a patch
includes a good fix, then go for it. If same patch ALso includes
formatting fixes, then accept it and fix the whitespace issues later.
If said patch fixes a real bug, accept it. The formatting can be fixed
later.
Whitespace (in and of itself) is not that big a deal (unless the
formatting is terribly wrong in which case, we tell the patcher to @
least try to adhere.) and can be easily ignored (if patch reviewer
just looks @ the code itself). The only thing unacceptable (imo) is all
this wasted whitespace wrt trying to align variables. We all know what
I am talking about:
Evas_Object *myobj;
Evas *myevas;
Is Easier to read (cause human brain normally goes left to right), Than:
Evas_Object *myobh
Evas *myevas
Now, I have to read hey, there's an Evas ... let me page over and see
what the variable name is ... UUGGG What a waste (of time AND
whitespace)...
Having said that:
If the fix is good, then the formatting can be fixed later...just my
2 cents
dh
well, I was mainly talking about trailing whitespaces (which are not
formatting-related). I suppose I should have specified. I do agree with
your
points, however.
Ahhh, Trailing whitespaces...I see. Yea, those can be annoying, but
sometimes they are not avoidable. I know that code I write sometimes
has them, but it's normally the 'editor' which is doing it. Ie, if I
write a line:
if (variable) {
then while writing it, when I get to the bracket my editor automatically
puts the bracket on the next line (with the proper indented space for
efl formatting) and what gets left is what looks like a 'trailing'
whitespace.
Mine do remove the trailing whitespace in that case...
And an easier solution is to simply highlight them...
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
Not sure what you are referring to here...what is it that he did ??
She
Sent from my iPod
On Dec 27, 2011, at 4:45 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore_Evas (Wayland_Shm):
Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame
w/ the title).
Couldn't you reuse in some way what Gustavo did in the EWL backend ?
Add support for size_min/max/base/step setting.
Add support for title name_class setting.
Add support for setting a cursor.
Add support for hiding an ecore_evas.
Author: devilhorns
Date: 2011-12-27 11:25:38 -0800 (Tue, 27 Dec 2011)
New Revision: 66578
Trac: http://trac.enlightenment.org/e/changeset/66578
Modified:
trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c
Modified: trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c
===
--- trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c 2011-12-27
19:12:56 UTC (rev 66577)
+++ trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c 2011-12-27
19:25:38 UTC (rev 66578)
@@ -31,6 +31,15 @@
# include Evas_Engine_Wayland_Shm.h
# include Ecore_Wayland.h
+/* local structures */
+typedef struct _EE_Wl_Smart_Data EE_Wl_Smart_Data;
+struct _EE_Wl_Smart_Data
+{
+ Evas_Object *frame;
+ Evas_Object *text;
+ Evas_Coord x, y, w, h;
+};
+
/* local function prototypes */
static int _ecore_evas_wl_init(void);
static int _ecore_evas_wl_shutdown(void);
@@ -43,6 +52,15 @@
static void _ecore_evas_wl_callback_focus_out_set(Ecore_Evas *ee, void
(*func)(Ecore_Evas *ee));
static void _ecore_evas_wl_resize(Ecore_Evas *ee, int w, int h);
static void _ecore_evas_wl_show(Ecore_Evas *ee);
+static void _ecore_evas_wl_hide(Ecore_Evas *ee);
+static void _ecore_evas_wl_title_set(Ecore_Evas *ee, const char *t);
+static void _ecore_evas_wl_name_class_set(Ecore_Evas *ee, const char *n,
const char *c);
+static void _ecore_evas_wl_size_min_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_max_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_base_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_step_set(Ecore_Evas *ee, int w, int h);
+static vo
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 16:45, Cedric BAIL wrote:
On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore_Evas (Wayland_Shm):
Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle
frame w/ the title).
Couldn't you reuse in some way what Gustavo did in the EWL backend ?
Are you referring to the old ewl toolkit here ?
dh
Add support for size_min/max/base/step setting.
Add support for title name_class setting.
Add support for setting a cursor.
Add support for hiding an ecore_evas.
Author: devilhorns
Date: 2011-12-27 11:25:38 -0800 (Tue, 27 Dec 2011)
New Revision: 66578
Trac: http://trac.enlightenment.org/e/changeset/66578
Modified:
trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c
Modified: trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c
===
--- trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c 2011-12-27
19:12:56 UTC (rev 66577)
+++ trunk/ecore/src/lib/ecore_evas/ecore_evas_wayland_shm.c 2011-12-27
19:25:38 UTC (rev 66578)
@@ -31,6 +31,15 @@
# includeEvas_Engine_Wayland_Shm.h
# includeEcore_Wayland.h
+/* local structures */
+typedef struct _EE_Wl_Smart_Data EE_Wl_Smart_Data;
+struct _EE_Wl_Smart_Data
+{
+ Evas_Object *frame;
+ Evas_Object *text;
+ Evas_Coord x, y, w, h;
+};
+
/* local function prototypes */
static int _ecore_evas_wl_init(void);
static int _ecore_evas_wl_shutdown(void);
@@ -43,6 +52,15 @@
static void _ecore_evas_wl_callback_focus_out_set(Ecore_Evas *ee, void
(*func)(Ecore_Evas *ee));
static void _ecore_evas_wl_resize(Ecore_Evas *ee, int w, int h);
static void _ecore_evas_wl_show(Ecore_Evas *ee);
+static void _ecore_evas_wl_hide(Ecore_Evas *ee);
+static void _ecore_evas_wl_title_set(Ecore_Evas *ee, const char *t);
+static void _ecore_evas_wl_name_class_set(Ecore_Evas *ee, const char *n,
const char *c);
+static void _ecore_evas_wl_size_min_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_max_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_base_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_size_step_set(Ecore_Evas *ee, int w, int h);
+static void _ecore_evas_wl_object_cursor_set(Ecore_Evas *ee, Evas_Object
*obj, int layer, int hot_x, int hot_y);
+static void _ecore_evas_wl_object_cursor_del(void *data, Evas *evas
__UNUSED__, Evas_Object *obj __UNUSED__, void *event __UNUSED__);
static int _ecore_evas_wl_render(Ecore_Evas *ee);
static void _ecore_evas_wl_screen_geometry_get(const Ecore_Evas *ee
__UNUSED__, int *x, int *y, int *w, int *h);
static void _ecore_evas_wl_buffer_new(Ecore_Evas *ee, void **dest);
@@ -56,6 +74,18 @@
static Eina_Bool _ecore_evas_wl_event_focus_in(void *data __UNUSED__, int
type __UNUSED__, void *event);
static Eina_Bool _ecore_evas_wl_event_focus_out(void *data __UNUSED__, int
type __UNUSED__, void *event);
+/* SMART stuff for frame */
+static Evas_Smart *_ecore_evas_wl_smart = NULL;
+
+static void _ecore_evas_wl_smart_init(void);
+static void _ecore_evas_wl_smart_add(Evas_Object *obj);
+static void _ecore_evas_wl_smart_del(Evas_Object *obj);
+static void _ecore_evas_wl_smart_resize(Evas_Object *obj, Evas_Coord w,
Evas_Coord h);
+static void _ecore_evas_wl_smart_show(Evas_Object *obj);
+static void _ecore_evas_wl_smart_hide(Evas_Object *obj);
+
+static Evas_Object *_ecore_evas_wl_frame_add(Evas *evas);
+
/* local variables */
static int _ecore_evas_wl_init_count = 0;
static Ecore_Event_Handler *_ecore_evas_wl_event_handlers[8];
@@ -84,17 +114,17 @@
NULL, // func rotation set
NULL, // func shaped set
_ecore_evas_wl_show,
- NULL, // func hide
+ _ecore_evas_wl_hide,
NULL, // func raise
NULL, // func lower
NULL, // func activate
- NULL, // func title set
- NULL, // func name_class set
- NULL, // func size min set
- NULL, // func size max set
- NULL, // func size base set
- NULL, // func size step set
- NULL, // func object cursor set
+ _ecore_evas_wl_title_set,
+ _ecore_evas_wl_name_class_set,
+ _ecore_evas_wl_size_min_set,
+ _ecore_evas_wl_size_max_set,
+ _ecore_evas_wl_size_base_set,
+ _ecore_evas_wl_size_step_set,
+ _ecore_evas_wl_object_cursor_set,
NULL, // func layer set
NULL, // func focus set
NULL, // func iconified set
@@ -200,6 +230,13 @@
* engine destination */
ecore_evas_callback_pre_free_set(ee, _ecore_evas_wl_pre_free);
+ if (ee-prop.draw_frame)
+ {
+ee-engine.wl.frame = _ecore_evas_wl_frame_add(ee-evas);
+evas_object_is_frame_object_set(ee-engine.wl.frame, EINA_TRUE);
+evas_object_move(ee-engine.wl.frame, 0, 0);
+ }
+
ecore_evas_input_event_register(ee);
_ecore_evas_register(ee);
@@ -281,6 +318,9 @@
LOGFN(__FILE__, __LINE__,
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.orgwrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? dh -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: andreas trunk/BINDINGS/cxx/elementaryxx/include/elementaryxx
Thanks. But I pointed out elementaryxx build break before and nobody answered. However I still have a build break there. Something is still missing? make[2]: *** No rule to make target `GenListItem.lo', needed by `libelementaryxx.la'. make[2]: Target `all' not remade because of errors. Daniel Juyung Seo (SeoZ) On Wed, Dec 28, 2011 at 2:53 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: ups, forgot to commit a file - nobody noticed :-( - good choose to build now daily on launchpad... Author: andreas Date: 2011-12-27 09:53:29 -0800 (Tue, 27 Dec 2011) New Revision: 66576 Trac: http://trac.enlightenment.org/e/changeset/66576 Added: trunk/BINDINGS/cxx/elementaryxx/include/elementaryxx/GenListItem.h -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-svn mailing list enlightenment-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. dh -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.orgwrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. dh -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? What are you going to do? draw the border using only evas commands, no themes? no nothing? If you're getting themes, you pull in edje, then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) IMO it's not something for ecore or evas. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 21:42, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window managerdecorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? Just insane ;) What are you going to do? draw the border using only evas commands, no themes? no nothing? Yup. It's just a basic frame (a boring rectangle) If you're getting themes, you pull in edje, Right, which is why the ecore_evas frame is just a boring rectangle so we don't pull in edje there. then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) Sure, and elm will have the option of doing the window decorations (frame) itself if needed/wanted. dh IMO it's not something for ecore or evas. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, Dec 28, 2011 at 12:47 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:42, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? Just insane ;) What are you going to do? draw the border using only evas commands, no themes? no nothing? Yup. It's just a basic frame (a boring rectangle) If you're getting themes, you pull in edje, Right, which is why the ecore_evas frame is just a boring rectangle so we don't pull in edje there. then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) Sure, and elm will have the option of doing the window decorations (frame) itself if needed/wanted. if nobody is going to use it, why doing it? for those not willing to use elm, my bet is that we should provide a simple example as BSD so people can copypaste it, modifying to satisfy needs. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 21:51, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:47 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:42, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.orgwrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? Just insane ;) What are you going to do? draw the border using only evas commands, no themes? no nothing? Yup. It's just a basic frame (a boring rectangle) If you're getting themes, you pull in edje, Right, which is why the ecore_evas frame is just a boring rectangle so we don't pull in edje there. then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) Sure, and elm will have the option of doing the window decorations (frame) itself if needed/wanted. if nobody is going to use it, why doing it? Well, it needs the ability to do it just in case someone makes an app not using elm, but still wants to provide a frame. If they are not using elm, then ecore_evas can optionally draw a basic rectangle frame, OR they can supply their own evas_object to handle it. A simple shot showing the 'frame' for ecore_evas. It's nothing fancy (and is not meant to be) but it does/will provide a way to move windows around by grabbing the frame. http://i.imgur.com/9G9EY.jpg There are no 'borders' on the elm test app in this shot cause I am still hashing out that part of the code. for those not willing to use elm, my bet is that we should provide a simple example as BSD so people can copypaste it, modifying to satisfy needs. Yea, I have some example code here already, just not in svn yet. dh -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, Dec 28, 2011 at 12:57 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:51, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:47 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:42, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? Just insane ;) What are you going to do? draw the border using only evas commands, no themes? no nothing? Yup. It's just a basic frame (a boring rectangle) If you're getting themes, you pull in edje, Right, which is why the ecore_evas frame is just a boring rectangle so we don't pull in edje there. then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) Sure, and elm will have the option of doing the window decorations (frame) itself if needed/wanted. if nobody is going to use it, why doing it? Well, it needs the ability to do it just in case someone makes an app not using elm, but still wants to provide a frame. If they are not using elm, then ecore_evas can optionally draw a basic rectangle frame, OR they can supply their own evas_object to handle it. A simple shot showing the 'frame' for ecore_evas. It's nothing fancy (and is not meant to be) but it does/will provide a way to move windows around by grabbing the frame. http://i.imgur.com/9G9EY.jpg There are no 'borders' on the elm test app in this shot cause I am still hashing out that part of the code. if we don't do this for fb, directfb, windows or x11, why would we do it for wayland? really, if someone is willing to write barebone app using ecore_evas directly, he can deal with that, or live without it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Write once. Port to many. Get the SDK and tools to simplify
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On 12/27/11 22:04, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:57 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:51, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:47 AM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 21:42, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.netwrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window managerdecorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? Just insane ;) What are you going to do? draw the border using only evas commands, no themes? no nothing? Yup. It's just a basic frame (a boring rectangle) If you're getting themes, you pull in edje, Right, which is why the ecore_evas frame is just a boring rectangle so we don't pull in edje there. then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) Sure, and elm will have the option of doing the window decorations (frame) itself if needed/wanted. if nobody is going to use it, why doing it? Well, it needs the ability to do it just in case someone makes an app not using elm, but still wants to provide a frame. If they are not using elm, then ecore_evas can optionally draw a basic rectangle frame, OR they can supply their own evas_object to handle it. A simple shot showing the 'frame' for ecore_evas. It's nothing fancy (and is not meant to be) but it does/will provide a way to move windows around by grabbing the frame. http://i.imgur.com/9G9EY.jpg There are no 'borders' on the elm test app in this shot cause I am still hashing out that part of the code. if we don't do this for fb, directfb, windows or x11, why would we do it for wayland? really, if someone is willing to write barebone app using ecore_evas directly, he can deal with that, or live without it. Right, and if they do, then they would need a way to tell ecore_evas about their frame thus the ability to provide an evas_object to be used for that. If they don't want to provide their own frame, then they can tell ecore_evas to use the
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, 28 Dec 2011 00:16:56 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. the only thing he can re-use is the basic border drawing (layout) code in ecore-evas. the rest is wayland specific. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_evas
On Wed, 28 Dec 2011 01:04:13 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Wed, Dec 28, 2011 at 12:57 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:51, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:47 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:42, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:34 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:26, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:20 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 21:16, Gustavo Sverzut Barbieri wrote: On Wed, Dec 28, 2011 at 12:03 AM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 20:42, Gustavo Sverzut Barbieri wrote: On Tue, Dec 27, 2011 at 11:01 PM, Christopher Michael cpmicha...@comcast.net wrote: On 12/27/11 16:45, Cedric BAIL wrote: On Tue, Dec 27, 2011 at 8:25 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore_Evas (Wayland_Shm): Add an actual 'frame' to ecore_evas_wayland. (just a boring rectangle frame w/ the title). Couldn't you reuse in some way what Gustavo did in the EWL backend ? Are you referring to the old ewl toolkit here ? he means EWS - Evas+Ecore Windowing System. Ahhh ok. Well, what exactly is ews ? and what use could it be here ? I'm not following wayland patches, but EWS implements a windowing system, with a window manager and all (decorations provided by elementary's wm). It's single process, so you can run all your elementary_test windows in framebuffer or playstation3. I had no need for things like frame windows and such, found it strange. But likely raster is reviewing your code and it does make sense, no idea on my side. And I haven't been following ews patches, lol :) But I am curious now ... how does ews implement a window manager decorations ? I haven't seen anything in elementary that does decorations (or for that matter, a window manager). Also not sure if 'single process' would be sufficient in a wayland case :/ there are no patches, code is in ecore_evas and elementary for months already. ecore_evas posts ecore_events that the manager is supposed to use and do whatever is required, like adding decorations. elementary's code will implement this and register to events, creating edje to decorate it: http://trac.enlightenment.org/e/browser/trunk/elementary/src/lib/elu_ews_wm.c Ahh I see. as for single process, that what was required. if one added a way to get windows from other process is just a matter of doing the shm. But I did not, as wayland was supposed to do it. :-) Well, we are not making 'frame windows' (as such), just ability for ecore_evas to draw it's own frames Around windows (read: decorations)...or for elm to do it, etc. Still don't get it. What's the need to have these? Isn't just the window maker (elm_win) to draw its stuff and that's it? what's up with it at Evas level? Well, what happens if someone makes an efl app that does not use elm ? Ecore_Evas would still need a way to draw a 'frame' around the window. are you kidding or insane? Just insane ;) What are you going to do? draw the border using only evas commands, no themes? no nothing? Yup. It's just a basic frame (a boring rectangle) If you're getting themes, you pull in edje, Right, which is why the ecore_evas frame is just a boring rectangle so we don't pull in edje there. then not in ecore-evas... a separate library? if so, why not elm? that's why I put it like that, elm pulls in ecore, evas, ecore_evas and edje, all nice to do it... plus ship with a theme :-) Sure, and elm will have the option of doing the window decorations (frame) itself if needed/wanted. if nobody is going to use it, why doing it? Well, it needs the ability to do it just in case someone makes an app not using elm, but still wants to provide a frame. If they are not using elm, then ecore_evas can optionally draw a basic rectangle frame, OR they can supply their own evas_object to handle it. A simple shot showing the 'frame' for ecore_evas. It's nothing fancy (and is not meant to be) but it does/will provide a way to move windows around by grabbing the frame. http://i.imgur.com/9G9EY.jpg There are no 'borders' on the elm test app in this shot cause I am still hashing out that part of the code. if we don't do this for fb, directfb, windows or x11, why would we do it for wayland? windows already draws its own borders and the way rendering is handled draws to a sub-region of the window and borders are drawn by the standard
[E-devel] E17: Bug in mouse pointer shape
Hi, I'm seeing a bug there. When I move the mouse pointer to a corner of a window, it changes shape to look like a corner. Normal behavior. But the problem is that it is not changing back to the normal pointer shape when, after, I move it to an other place of the window. It is stuck to the corner shape. Not sure if I am clear. I can send a screenshot if you want. -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Check existence of evas_image_loader
On Mon, 26 Dec 2011 16:05:48 +0100 Guillaume Friloux guillaume.fril...@asp64.com said: Hello e people. If evas cant find the type of a file, it will try to use evas_image_loader, but not everyone has it. This will not block anything or crash, because the error is handled, but it is somehow ugly because you spend time building the command line and gets ugly messages to stderr. So here is a very simple patch to save some cycles in case you dont have the binary, and less spams your terminal. Please review it, it is my very first patch for evas and i know nothing about evas (i reported the bug and been asked to do the patch) We should save a lot more time by checking the existence of evas_image_loader once at startup and keep that information in memory instead of doing the check everytime, so i think some people here can do better than me with that already done by cedric yesterday but put in the right spot. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elc_ctxpopup, using elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
Understood the problem.
It's more acceptable to freeze the scroller only.
in. rev 66584
Thank you.
-Regards, Hermet-
-Original Message-
From: cnooklt;kimci...@gmail.comgt;
To: EFLlt;enlightenment-devel@lists.sourceforge.netgt;
Cc:
Sent: 11-12-27(화) 22:02:11
Subject: [E-devel] [Patch] elc_ctxpopup, using elm_smart_scroller_freeze_set()
not elm_object_scroll_freeze_push(), pop()
Dear All, Hello~
The ctxpopup had used elm_ojbect_scroll_freeze_push(), pop() for the
scroll-freeze-on,of callback.
If user calls elm_object_scroll_freeze_pop() only after
elm_ojbect_scroll_freeze_push(), then it will be fine.
But sometimes user calls elm_object_scroll_freeze_pop() two times in a
row.. Then you can find there is infinite loop in following..
EAPI void
elm_widget_scroll_freeze_pop(Evas_Object *obj)
{
API_ENTRY return;
sd-scroll_freeze--;
if (sd-scroll_freeze lt; 0) sd-scroll_freeze = 0;
if (!sd-scroll_freeze)
evas_object_smart_callback_call(obj, scroll-freeze-off, obj);
if (sd-parent_obj) elm_widget_scroll_freeze_pop(sd-parent_obj);
}
ctxpopup calls elm_widget_scroll_freeze_pop(wd-scr);finally. wd-scr
is widget data of ctxpopup.
Now the the sd-parent_obj is ctxpopup, next time
evas_object_smart_callback_call(obj, scroll-freeze-off, obj); is
called again by using ctxpopup as obj.
Anyhow, other widgets..
the ctxpopup should use elm_smart_scroller_freeze_set() with an attached patch.
Sincerely,
Shinwoo Kim.
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17: Bug in mouse pointer shape
I am not seeing this issue in my e17 desktop, though I find another behaviour. If I start resizing the window rapidly and stop at some point, the window is not of the shape I resize it to. It is of the resized to a previous position of the mouse cursor. I expect the window to follow and resize itself to where I drag it. Regards, Sanjeev -Original Message- From: Jérôme Pinot [mailto:ngc...@gmail.com] Sent: Wednesday, December 28, 2011 12:37 PM To: e-devel Subject: [E-devel] E17: Bug in mouse pointer shape Hi, I'm seeing a bug there. When I move the mouse pointer to a corner of a window, it changes shape to look like a corner. Normal behavior. But the problem is that it is not changing back to the normal pointer shape when, after, I move it to an other place of the window. It is stuck to the corner shape. Not sure if I am clear. I can send a screenshot if you want. -- Jérôme Pinot http://ngc891.blogdns.net/ -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][elm_map] Pause progressbar animator when map is paused
On Tue, 27 Dec 2011 10:30:48 +0900 Bluezery ohpo...@gmail.com said: When map is paused by using elm_map_paused_set(), all existing animations is stopped. (ref: http://docs.enlightenment.org/auto/elementary/group__Map.html#ga6ab43ef6429140f8cccbd3669c5ed52e) But progress bar can be still running before all download requests are completed. It is equal to user expectations. I have fixed this. if paused is TRUE, stop progress bar. If paused is FALSE, start progress bar if download requests are remained. in svn! :) tnx! -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_conform patch
On Tue, 27 Dec 2011 14:02:26 + (GMT) PRINCE KUMAR DUBEY prince.du...@samsung.com said: indeed good point. patch in svn! tnx! :) Hi, Attachment to the mail is elm_conform patch. Change Description: When no geometry information of ind/sft/kbd, resetting the geometry. Thanks, Prince -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17: Bug in mouse pointer shape
On Wed, Dec 28, 2011 at 1:19 PM, Sanjeev as290...@samsung.com wrote: I am not seeing this issue in my e17 desktop, though I find another behaviour. I have the same problem and it's so annoying :) Where to look at? Daniel Juyung Seo (SeoZ) If I start resizing the window rapidly and stop at some point, the window is not of the shape I resize it to. It is of the resized to a previous position of the mouse cursor. I expect the window to follow and resize itself to where I drag it. Regards, Sanjeev -Original Message- From: Jérôme Pinot [mailto:ngc...@gmail.com] Sent: Wednesday, December 28, 2011 12:37 PM To: e-devel Subject: [E-devel] E17: Bug in mouse pointer shape Hi, I'm seeing a bug there. When I move the mouse pointer to a corner of a window, it changes shape to look like a corner. Normal behavior. But the problem is that it is not changing back to the normal pointer shape when, after, I move it to an other place of the window. It is stuck to the corner shape. Not sure if I am clear. I can send a screenshot if you want. -- Jérôme Pinot http://ngc891.blogdns.net/ -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] fix build warning in scim-immodule
+1 Here. As I know, he's been EFL Programming over 3 years. He will be a good member to improve our EFL. Thank u. -Regards, Hermet- -Original Message- From: Daniel Juyung Seolt;seojuyu...@gmail.comgt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt; Cc: Sent: 11-12-28(수) 08:06:18 Subject: Re: [E-devel] [PATCH] fix build warning in scim-immodule +1 here. He's been sending many patches so far and done a good job mainly on ecore imf. Daniel Juyung Seo (SeoZ) On Tue, Dec 27, 2011 at 11:28 PM, Cedric BAIL lt;cedric.b...@free.frgt; wrote: On Tue, Dec 27, 2011 at 3:13 PM, Iván Briano (Sachiel) lt;sachi...@gmail.comgt; wrote: 2011/12/27 Jihoon Kim lt;imfin...@gmail.comgt;: Here are two simple patches. 'fix_warning_scim_imcontext.patch' is for fixing build warning 'warning: unused parameter' in scim-immodule. 'fix_indent_Makefile.patch' is for fixing indentation of Makefile.am in immodules/scim directory. Would you please apply in svn? In, both at once. I changed the warning fix to include config.h at the top, as that's what we do everywhere else. I'm also wondering if your next patch shouldn't be an info.txt file and your public key. Sounds like a lazy way to get the work done faster and better as Jihoon has been annoyingly sending patch that get in svn quite fast since sometimes now. So I vote that we get less work and put the burden on him by giving him svn access. -- Cedric BAIL -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Is anyone else seeing this issue?
CCLD edje_external_inspector /home/sanjeev/e/lib/libecore_evas.so.1: undefined reference to `evas_event_down_count_get' collect2: ld returned 1 exit status make[4]: *** [edje_external_inspector] Error 1 make[4]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src/bin' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sanjeev/source/e/trunk/edje' make: *** [all] Error 2 I did a distclean and rm -fr evas libraries in installed path. But, still cannot get past this. Another issue I see is, I install 'e' in my $HOME folder, but files get installed in /usr/local/lib as well. I do provide --prefix=$HOME/e/ for all my component builds, but still see the following. sanjeev@desktop:/usr/local/lib$ ls e* elementary_testql.a elementary_testql.la elementary_testql.so ecore: immodules edje: modules utils efreet: efreet_desktop_cache_create efreet_icon_cache_create elementary: modules enlightenment: modules preload utils evas: modules utils -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is anyone else seeing this issue?
On Wed, 28 Dec 2011 13:47:00 +0900 Sanjeev BA as290...@samsung.com said: CCLD edje_external_inspector /home/sanjeev/e/lib/libecore_evas.so.1: undefined reference to `evas_event_down_count_get' collect2: ld returned 1 exit status make[4]: *** [edje_external_inspector] Error 1 make[4]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src/bin' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sanjeev/source/e/trunk/edje' make: *** [all] Error 2 I did a distclean and rm -fr evas libraries in installed path. But, still cannot get past this. you didnt do an svn update on evas then. :)( Another issue I see is, I install 'e' in my $HOME folder, but files get installed in /usr/local/lib as well. I do provide --prefix=$HOME/e/ for all my component builds, but still see the following. err which files? i find this very hard to believe as this would have broken packaging many times over and we have zero complaints there - and have had for a very loong time. sanjeev@desktop:/usr/local/lib$ ls e* elementary_testql.a elementary_testql.la elementary_testql.so 2:01PM ~/C/elm ./configure --prefix=/opt/blah ... 2:04PM ~ find /opt/blah | grep elementary_testql /opt/blah/bin/elementary_testql /opt/blah/lib/elementary_testql.a /opt/blah/lib/elementary_testql.so /opt/blah/lib/elementary_testql.la 2:04PM ~ ls /usr/local/lib/elementary_testql* zsh: no matches found: /usr/local/lib/elementary_testql* ecore: immodules 1:59PM ~/C/ecore ./configure --prefix=/opt/blah ... 1:58PM ~ find /opt/blah | grep immodules /opt/blah/lib/ecore/immodules /opt/blah/lib/ecore/immodules/xim.la /opt/blah/lib/ecore/immodules/scim.so /opt/blah/lib/ecore/immodules/xim.so /opt/blah/lib/ecore/immodules/scim.la 1:59PM ~ ls /usr/local/lib/ecore ls: cannot access /usr/local/lib/ecore: No such file or directory ... i'm not going to test the below, but my bets are they are aloso just fine and dandy and you are/have been doing something wrong. edje: modules utils efreet: efreet_desktop_cache_create efreet_icon_cache_create elementary: modules enlightenment: modules preload utils evas: modules utils -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ 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 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is anyone else seeing this issue?
Ok, The set of old libs in /usr/local/lib were causing the problem. I checked the timestamps, deleted them and now 'e' installs in fine. On 12/28/2011 02:05 PM, Carsten Haitzler (The Rasterman) wrote: On Wed, 28 Dec 2011 13:47:00 +0900 Sanjeev BAas290...@samsung.com said: CCLD edje_external_inspector /home/sanjeev/e/lib/libecore_evas.so.1: undefined reference to `evas_event_down_count_get' collect2: ld returned 1 exit status make[4]: *** [edje_external_inspector] Error 1 make[4]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src/bin' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sanjeev/source/e/trunk/edje/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sanjeev/source/e/trunk/edje' make: *** [all] Error 2 I did a distclean and rm -fr evas libraries in installed path. But, still cannot get past this. you didnt do an svn update on evas then. :)( Another issue I see is, I install 'e' in my $HOME folder, but files get installed in /usr/local/lib as well. I do provide --prefix=$HOME/e/ for all my component builds, but still see the following. err which files? i find this very hard to believe as this would have broken packaging many times over and we have zero complaints there - and have had for a very loong time. sanjeev@desktop:/usr/local/lib$ ls e* elementary_testql.a elementary_testql.la elementary_testql.so 2:01PM ~/C/elm ./configure --prefix=/opt/blah ... 2:04PM ~ find /opt/blah | grep elementary_testql /opt/blah/bin/elementary_testql /opt/blah/lib/elementary_testql.a /opt/blah/lib/elementary_testql.so /opt/blah/lib/elementary_testql.la 2:04PM ~ ls /usr/local/lib/elementary_testql* zsh: no matches found: /usr/local/lib/elementary_testql* ecore: immodules 1:59PM ~/C/ecore ./configure --prefix=/opt/blah ... 1:58PM ~ find /opt/blah | grep immodules /opt/blah/lib/ecore/immodules /opt/blah/lib/ecore/immodules/xim.la /opt/blah/lib/ecore/immodules/scim.so /opt/blah/lib/ecore/immodules/xim.so /opt/blah/lib/ecore/immodules/scim.la 1:59PM ~ ls /usr/local/lib/ecore ls: cannot access /usr/local/lib/ecore: No such file or directory ... i'm not going to test the below, but my bets are they are aloso just fine and dandy and you are/have been doing something wrong. edje: modules utils efreet: efreet_desktop_cache_create efreet_icon_cache_create elementary: modules enlightenment: modules preload utils evas: modules utils -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17: Bug in mouse pointer shape
On Wed, Dec 28, 2011 at 1:19 PM, Sanjeev as290...@samsung.com wrote: I am not seeing this issue in my e17 desktop, though I find another behaviour. I have the same problem and it's so annoying :) Where to look at? Resize is done in a mouse move handler. There is a mouse up handler to stop resize. I guess you need to do a final resize in the up handler. S. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Gadget Resize in Shelves no longer an option
Was the ability to resize gadgets that exist on a shelf removed intentionally? -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
