[E-devel] [PATCH] edje
Hi!
This patch fixes the computation of edje parts. Earlier the down right
corner was at ((1.0, 1.0), (-1, -1)) and now it is at ((1.0, 1.0), (0,
0)) as it should be. E runs fine with the patch applied, but the theme
is a bit screwed.
What is the purpose of adding 1? Is it so that w = 0 and h = 0 shouldn't
be returned? That should be done somewhere else.
I also tried to fix the default theme for E, but I'm not sure everything
is correct, and I didn't fix the ibar. Which still has to be ported to
gadman anyhow.
Sebastian
Index: edje/src/lib/Edje.h
===
RCS file: /cvsroot/enlightenment/e17/libs/edje/src/lib/Edje.h,v
retrieving revision 1.39
diff -u -b -B -r1.39 Edje.h
--- edje/src/lib/Edje.h 28 Nov 2004 14:52:01 - 1.39
+++ edje/src/lib/Edje.h 7 Feb 2005 09:16:35 -
@@ -1,3 +1,6 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ */
#ifndef _EDJE_H
#define _EDJE_H
Index: edje/src/lib/edje_calc.c
===
RCS file: /cvsroot/enlightenment/e17/libs/edje/src/lib/edje_calc.c,v
retrieving revision 1.59
diff -u -b -B -r1.59 edje_calc.c
--- edje/src/lib/edje_calc.c7 Jan 2005 08:35:27 - 1.59
+++ edje/src/lib/edje_calc.c7 Feb 2005 09:16:36 -
@@ -262,11 +262,11 @@
if (rel2_to_x)
params-w = desc-rel2.offset_x +
rel2_to_x-x + (desc-rel2.relative_x * rel2_to_x-w) -
- params-x + 1;
+ params-x;
else
params-w = desc-rel2.offset_x +
(desc-rel2.relative_x * ed-w) -
- params-x + 1;
+ params-x;
}
if (flags FLAG_Y)
{
@@ -279,11 +279,11 @@
if (rel2_to_y)
params-h = desc-rel2.offset_y +
rel2_to_y-y + (desc-rel2.relative_y * rel2_to_y-h) -
- params-y + 1;
+ params-y;
else
params-h = desc-rel2.offset_y +
(desc-rel2.relative_y * ed-h) -
- params-y + 1;
+ params-y;
}
/* aspect */
Index: e/data/themes/default_border.edc
===
RCS file: /cvsroot/enlightenment/e17/apps/e/data/themes/default_border.edc,v
retrieving revision 1.2
diff -u -b -B -r1.2 default_border.edc
--- e/data/themes/default_border.edc10 Jan 2005 22:33:53 - 1.2
+++ e/data/themes/default_border.edc7 Feb 2005 09:19:25 -
@@ -63,7 +63,7 @@
}
rel2 {
relative: 0.0 1.0;
- offset: 05;
+ offset: 06;
to_y: title2;
}
image {
@@ -85,7 +85,7 @@
}
rel2 {
relative: 0.0 1.0;
- offset: -1 -1;
+ offset: 00;
to: t3;
}
image {
@@ -106,7 +106,7 @@
}
rel2 {
relative: 1.0 1.0;
- offset: -15;
+ offset: 06;
to_y: title2;
}
image {
@@ -127,7 +127,7 @@
}
rel2 {
relative: 1.0 0.0;
- offset: -1 -1;
+ offset: 00;
to_y: b2;
}
image {
@@ -149,7 +149,7 @@
}
rel2 {
relative: 1.0 1.0;
- offset: -1 -1;
+ offset: 00;
}
image {
normal: e17_border5.png;
@@ -168,7 +168,7 @@
}
rel2 {
relative: 0.0 1.0;
- offset: -1 -1;
+ offset: 00;
to: b2;
}
image {
@@ -190,7 +190,7 @@
}
rel2 {
relative: 0.0 1.0;
- offset: 3-1;
+ offset: 40;
}
image {
normal: e17_border7.png;
@@ -209,7 +209,7 @@
}
rel2 {
relative: 0.0 0.0;
- offset: 3-1;
+ offset: 40;
to_y: b4;
}
image {
@@ -235,7 +235,7 @@
}
rel2 {
relative: 0.0 1.0;
- offset: -24;
+ offset: 07;
to_x: t3;
to_y: title2;
}
@@ -257,7 +257,7 @@
}
rel2 {
relative: 0.0 1.0;
- offset: -24;
+ offset: 07;
to_x: t3;
to_y: title2;
}
@@ -281,7 +281,7 @@
}
rel2 {
relative: 1.0 1.0;
- offset: -1 -1;
+ offset: 00;
to: title_outline;
}
image {
@@ -300,7 +300,7 @@
}
rel2 {
relative: 1.0
[E-devel] [PATCH] ecore_x
Hi!
I've added functions for different _NET atoms, and fixed
ecore_x_netwm_state_isset and ecore_x_netwm_state_get
Also added some atoms and changed some. Used this EWMH spec:
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html
Sebastian
Index: ecore/src/lib/ecore_x/Ecore_X.h
===
RCS file: /cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore_x/Ecore_X.h,v
retrieving revision 1.94
diff -u -r1.94 Ecore_X.h
--- ecore/src/lib/ecore_x/Ecore_X.h 13 Jan 2005 07:13:06 - 1.94
+++ ecore/src/lib/ecore_x/Ecore_X.h 7 Feb 2005 09:31:19 -
@@ -724,7 +724,10 @@
/* The following are not documented because they are not
* intended for use in applications. */
ECORE_X_WINDOW_STATE_ABOVE,
-ECORE_X_WINDOW_STATE_BELOW
+ECORE_X_WINDOW_STATE_BELOW,
+
+/* FIXME: Documentation */
+ECORE_X_WINDOW_STATE_DEMANDS_ATTENTION
} Ecore_X_Window_State;
@@ -739,6 +742,19 @@
ECORE_X_WINDOW_TYPE_NORMAL
} Ecore_X_Window_Type;
+typedef enum _Ecore_X_Action {
+ECORE_X_ACTION_MOVE,
+ECORE_X_ACTION_RESIZE,
+ECORE_X_ACTION_MINIMIZE,
+ECORE_X_ACTION_SHADE,
+ECORE_X_ACTION_STICK,
+ECORE_X_ACTION_MAXIMIZE_HORZ,
+ECORE_X_ACTION_MAXIMIZE_VERT,
+ECORE_X_ACTION_FULLSCREEN,
+ECORE_X_ACTION_CHANGE_DESKTOP,
+ECORE_X_ACTION_CLOSE
+} Ecore_X_Action;
+
typedef enum _Ecore_X_Window_Configure_Mask {
ECORE_X_WINDOW_CONFIGURE_MASK_X = (1 0),
ECORE_X_WINDOW_CONFIGURE_MASK_Y = (1 1),
@@ -1080,6 +1096,7 @@
EAPI voidecore_x_netwm_desk_workareas_set(Ecore_X_Window
root, unsigned int n_desks, unsigned int *areas);
EAPI voidecore_x_netwm_desk_current_set(Ecore_X_Window
root, unsigned int desk);
EAPI voidecore_x_netwm_desk_viewports_set(Ecore_X_Window
root, unsigned int n_desks, unsigned int *origins);
+ EAPI voidecore_x_netwm_desk_layout_set(Ecore_X_Window root,
int orientation, int columns, int rows, int starting_corner);
EAPI voidecore_x_netwm_showing_desktop_set(Ecore_X_Window
root, int on);
EAPI voidecore_x_netwm_client_list_set(Ecore_X_Window root,
unsigned int n_clients, Ecore_X_Window * p_clients);
EAPI void
ecore_x_netwm_client_list_stacking_set(Ecore_X_Window root, unsigned int
n_clients, Ecore_X_Window * p_clients);
@@ -1094,11 +,33 @@
EAPI char *ecore_x_netwm_visible_icon_name_get(Ecore_X_Window
win);
EAPI voidecore_x_netwm_desktop_set(Ecore_X_Window win,
unsigned int desk);
EAPI int ecore_x_netwm_desktop_get(Ecore_X_Window win,
unsigned int *desk);
- EAPI voidecore_x_netwm_opacity_set(Ecore_X_Window win,
unsigned int opacity);
- EAPI int ecore_x_netwm_opacity_get(Ecore_X_Window win,
unsigned int *opacity);
+ EAPI voidecore_x_netwm_strut_set(Ecore_X_Window win, int
left, int right, int top, int bottom);
+ EAPI int ecore_x_netwm_strut_get(Ecore_X_Window win, int
*left, int *right, int *top, int *bottom);
+ EAPI voidecore_x_netwm_strut_partial_set(Ecore_X_Window
win, int left, int right, int top, int bottom, int left_start_y, int
left_end_y, int right_start_y, int right_end_y, int top_start_x, int top_end_x,
int bottom_start_x, int bottom_end_x);
+ EAPI int ecore_x_netwm_strut_partial_get(Ecore_X_Window
win, int *left, int *right, int *top, int *bottom, int *left_start_y, int
*left_end_y, int *right_start_y, int *right_end_y, int *top_start_x, int
*top_end_x, int *bottom_start_x, int *bottom_end_x);
+ EAPI voidecore_x_netwm_icon_geometry_set(Ecore_X_Window
win, int x, int y, int width, int height);
+ EAPI int ecore_x_netwm_icon_geometry_get(Ecore_X_Window
win, int *x, int *y, int *width, int *height);
+#if 0
+ /* FIXME */
+ EAPI voidecore_x_netwm_icon_set();
+ EAPI int ecore_x_netwm_icon_get();
+#endif
+ EAPI voidecore_x_netwm_pid_set(Ecore_X_Window win, int pid);
+ EAPI int ecore_x_netwm_pid_get(Ecore_X_Window win, int
*pid);
+ EAPI voidecore_x_netwm_handled_icons_set(Ecore_X_Window
win);
+ EAPI int ecore_x_netwm_handled_icons_get(Ecore_X_Window
win);
+ EAPI voidecore_x_netwm_user_time_set(Ecore_X_Window win,
int time);
+ EAPI int ecore_x_netwm_user_time_get(Ecore_X_Window win,
int *time);
+
EAPI voidecore_x_netwm_window_state_set(Ecore_X_Window win,
Ecore_X_Window_State state, int on);
EAPI int ecore_x_netwm_window_state_isset(Ecore_X_Window
win, Ecore_X_Window_State state);
+ EAPI voidecore_x_netwm_window_type_set(Ecore_X_Window win,
Ecore_X_Window_Type type);
+ EAPI
Re: [E-devel] [PATCH] edje
On Mon, 07 Feb 2005 10:26:34 +0100 Sebastian Dransfeld [EMAIL PROTECTED] babbled: Hi! This patch fixes the computation of edje parts. Earlier the down right corner was at ((1.0, 1.0), (-1, -1)) and now it is at ((1.0, 1.0), (0, 0)) as it should be. E runs fine with the patch applied, but the theme is a bit screwed. What is the purpose of adding 1? Is it so that w = 0 and h = 0 shouldn't be returned? That should be done somewhere else. I also tried to fix the default theme for E, but I'm not sure everything is correct, and I didn't fix the ibar. Which still has to be ported to gadman anyhow. you should have asked first!@ :) i can't accept this because there are good reasons i have the system as it is. there are several kinds of layout and alignment that are MUCH easier doing it as 1.0 1.0 being the bottom-right PLUS 1. remember we are not defining the width, but defining the bottom-right PIXEL so the relative co-ords work 100% as you'd expect 1.0 == the width, but because we define the bottom-right pixel we need to do -1 -1. if we don't there are several layout systems that just can't be done anymore - i had things this way for a bit thinking "lets make it easy" but i found the problems :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] edje
Carsten Haitzler (The Rasterman) wrote: On Mon, 07 Feb 2005 10:26:34 +0100 Sebastian Dransfeld [EMAIL PROTECTED] babbled: Hi! This patch fixes the computation of edje parts. Earlier the down right corner was at ((1.0, 1.0), (-1, -1)) and now it is at ((1.0, 1.0), (0, 0)) as it should be. E runs fine with the patch applied, but the theme is a bit screwed. What is the purpose of adding 1? Is it so that w = 0 and h = 0 shouldn't be returned? That should be done somewhere else. I also tried to fix the default theme for E, but I'm not sure everything is correct, and I didn't fix the ibar. Which still has to be ported to gadman anyhow. you should have asked first!@ :) i can't accept this because there are good reasons i have the system as it is. there are several kinds of layout and alignment that are MUCH easier doing it as 1.0 1.0 being the bottom-right PLUS 1. remember we are not defining the width, but defining the bottom-right PIXEL so the relative co-ords work 100% as you'd expect 1.0 == the width, but because we define the bottom-right pixel we need to do -1 -1. if we don't there are several layout systems that just can't be done anymore - i had things this way for a bit thinking lets make it easy but i found the problems :) Hm. But if I have a widget sized 10x10, edje will calculate it as 9x9 in size. And that isn't right or? So first I cut on pixel away because I defined my lower right corner relative to (0, 0) and not (-1, -1), and one pixel is cut because of the wrong size. You might think it's brilliant, but it is a bit confusing for other. Sebastian --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] zone
Hi!
This should correct the problem with borders moving from one desk to
another.
Sebastian
Index: e_zone.c
===
RCS file: /cvsroot/enlightenment/e17/apps/e/src/bin/e_zone.c,v
retrieving revision 1.21
diff -u -r1.21 e_zone.c
--- e_zone.c22 Jan 2005 06:58:34 - 1.21
+++ e_zone.c7 Feb 2005 11:02:04 -
@@ -36,14 +36,13 @@
E_Zone *
e_zone_new(E_Container *con, int x, int y, int w, int h)
{
- E_Zone *zone;
- int i;
+ E_Zone *zone;
+ charname[40];
zone = E_OBJECT_ALLOC(E_Zone, E_ZONE_TYPE, _e_zone_free);
if (!zone) return NULL;
zone-container = con;
- zone-name = NULL;
zone-x = x;
zone-y = y;
@@ -51,6 +50,9 @@
zone-h = h;
zone-num = ++zone_count;
+ snprintf(name, sizeof(name), Zone %d, zone-num);
+ zone-name = strdup(name);
+
con-zones = evas_list_append(con-zones, zone);
if (1)
@@ -312,6 +314,7 @@
Evas_List *client;
E_Border *bd;
E_Event_Zone_Desk_Count_Set *ev;
+ E_Event_Border_Desk_Set *evb;
xx = x_count;
if (xx 1)
@@ -349,7 +352,7 @@
bd = (E_Border *) client-data;
new_desk-clients = evas_list_append(new_desk-clients, bd);
- bd-desk = new_desk;
+ e_border_desk_set(bd, new_desk);
client = client-next;
}
evas_list_free(desk-clients);
@@ -371,7 +374,7 @@
bd = (E_Border *) client-data;
new_desk-clients = evas_list_append(new_desk-clients, bd);
- bd-desk = new_desk;
+ e_border_desk_set(bd, new_desk);
client = client-next;
}
evas_list_free(desk-clients);
[E-devel] CVS access
Hi!
It seems like my patches usually get accepted. Is it possible to get cvs
commit access? I will send larger patch to the list, but it would be
nice to be able to fix things like adding
/*
* vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
*/
on files and doing formatting updates. It would also make other patches
from me easier to read.
Sebastian
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] CVS access
On Mon, 07 Feb 2005 12:45:01 +0100 Sebastian Dransfeld [EMAIL PROTECTED]
babbled:
Hi!
It seems like my patches usually get accepted. Is it possible to get cvs
commit access? I will send larger patch to the list, but it would be
nice to be able to fix things like adding
/*
* vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
*/
on files and doing formatting updates. It would also make other patches
from me easier to read.
i guess we could :)
just a few things. your first (big patch) adds features not on the mini-freeze
todo list (button bindings) - it'd be good to discuss this first and hear your
plans on how to tackle it. remember we likely have discussed things and designs
(we do a lot of it on irc).
it'd be good to join #e and #edevelop on irc.freenode.net. we like to know whats
going on - so people don't duplicate effort and that effort is done in the right
way :). it'd be good to discuss plans in e-mail/irc.
we'll be happy to give you access - it would just be nice to not have a few
thousand lines of patch to wade through :) do changes in small lots so we can
see it happening as it happens. :) the main aim is to keep quality control tight
and code clean and maintainable :) we are very glad to have help from people too
:)
so come "hang out"
btw - what's your sf.net username?
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: enlightenment-cvs digest, Vol 1 #3130 - 3 msgs
On Mon, 07 Feb 2005 20:18:35 PST, [EMAIL PROTECTED] said: +It is now possible to execute scripts on startup and/or restart. Use +$ eesh set misc.session.cmd_init script +to set the init script, and +$ eesh set misc.session.cmd_start script +to set the start script. +The init script is executed only the first time e16 is started on the +display, and the start script is run every time e16 (re)starts. Does 'init' mean the *FIRST* first time it's run (i.e. make it suitable for doing initial setup/version migration/etc), or is that the first time this X session it's been started? :) pgpASHzknvL2q.pgp Description: PGP signature
