Re: [E-devel] {Spam?} Re: E CVS: libs/edje pfritz

[Chady Kassouf]

On 7/7/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:

 On 7/7/07, Vincent Torri [EMAIL PROTECTED] wrote:
  On Sat, 7 Jul 2007, Dr. Michael 'Mickey' Lauer wrote:
 
   Vincent Torri wrote:
  
   On Fri, 6 Jul 2007, Enlightenment CVS wrote:
style = EVAS_TEXT_STYLE_OUTLINE_SHADOW;
  else if (ep-part-effect ==
 EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW)
style = EVAS_TEXT_STYLE_OUTLINE_SOFT_SHADOW;
   +  else if (ep-part-effect == EDJE_TEXT_EFFECT_FAR_SHADOW)
   +style = EVAS_TEXT_STYLE_FAR_SHADOW;
   +  else if (ep-part-effect ==
 EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW)
   +style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW;
   +  else if (ep-part-effect == EDJE_TEXT_EFFECT_GLOW)
   +style = EVAS_TEXT_STYLE_GLOW;
  
   #define EDJE_TEXT_EFFECT_SOFT_SHADOW 5
   #define EDJE_TEXT_EFFECT_OUTLINE_SHADOW  6
   #define EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW 7
   -#define EDJE_TEXT_EFFECT_LAST8
   +#define EDJE_TEXT_EFFECT_FAR_SHADOW  8
   +#define EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW 9
   +#define EDJE_TEXT_EFFECT_GLOW   10
   +#define EDJE_TEXT_EFFECT_LAST   11
  
   Isn't it better to use an enum + a switch, instead of defines +
 if/else ?
  
   FWIW, I agree. What we lose in runtime performance we gain more than
   twice in clarity and maintenance.
 
  I'm not sure we loose in runtime speed. switch are handle with lookup
  tables with enums (iirc), and the compiler can do better optimizations
  than with a bunch of if/else

 yep, it will not loose, and even if it was the case it would be so
 minimum and not worth more than maintenance.


I actually did a small test and compiled to assembly, an if/else will
compile to exactly the same amount of `cmpl` statements as a switch, and
almost the same amount of jumps. The only difference is in the logic of
branching: the compiler will compile an if/else to branch on the else part,
while the switch statement will always jump, so they're both jumping and
affecting the pipeline, but any performance difference between the two is
relative, and probably not noticeable.

-- 
Chady 'Leviathan' Kassouf
http://chady.net/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] compile patch for engycad

[Vincent Torri]

Hey,

here is a patch for the compilation of engy (no more *-config scripts are 
used now). I've also added math.h in a file


Nevertheless, on my computer (core2 duo, so 64 bits), the program does not 
work. There are a lots of cast from a pointer to an int (from edb, 
mainly, but not all). Maybe that's why it does not work


Also, edb is not maintained anymore. Maybe ecore-config shoud be used, 
instead.


Vincent? Makefile
? Makefile.in
? aclocal.m4
? autom4te.cache
? config.guess
? config.h
? config.log
? config.status
? config.sub
? configure
? default-drawing.db
? depcomp
? engy.diff
? install-sh
? libtool
? ltmain.sh
? missing
? stamp-h1
? resources/Makefile
? resources/Makefile.in
? resources/fonts/Makefile
? resources/fonts/Makefile.in
? resources/help/Makefile
? resources/help/Makefile.in
? resources/pics/Makefile
? resources/pics/Makefile.in
? resources/templates/Makefile
? resources/templates/Makefile.in
? resources/tools/Makefile
? resources/tools/Makefile.in
? src/.deps
? src/.libs
? src/Makefile
? src/Makefile.in
? src/engycad
Index: configure.in
===
RCS file: /cvs/e/e17/apps/engycad/configure.in,v
retrieving revision 1.1
diff -u -r1.1 configure.in
--- configure.in8 Jul 2007 04:15:48 -   1.1
+++ configure.in8 Jul 2007 07:37:23 -
@@ -38,57 +38,8 @@
 packagesrcdir=`cd $srcdir  pwd`
 AC_DEFINE_UNQUOTED(PACKAGE_SOURCE_DIR, ${packagesrcdir})
 
-PROG=imlib2-config;
-AC_PATH_PROG(IMLIB2_CONFIG, $PROG, , $PATH)
-if [ test -z $IMLIB2_CONFIG ]; then
-  echo $PROG  is not in your \$PATH. Please ensure it is.;
-  echo Read the manual page for you shell as to how to extend your path.;
-  echo FATAL ERROR. ABORT.;
-  exit -1;
-fi
-imlib2_cflags=`$IMLIB2_CONFIG --cflags`
-imlib2_libs=`$IMLIB2_CONFIG --libs`
-AC_SUBST(imlib2_cflags)
-AC_SUBST(imlib2_libs)
-
-PROG=evas-config;
-AC_PATH_PROG(EVAS_CONFIG, $PROG, , $PATH)
-if [ test -z $EVAS_CONFIG ]; then
-  echo $PROG  is not in your \$PATH. Please ensure it is.;
-  echo Read the manual page for you shell as to how to extend your path.;
-  echo FATAL ERROR. ABORT.;
-  exit -1;
-fi
-evas_cflags=`$EVAS_CONFIG --cflags`
-evas_libs=`$EVAS_CONFIG --libs`
-AC_SUBST(evas_cflags)
-AC_SUBST(evas_libs)
-
-PROG=edb-config;
-AC_PATH_PROG(EDB_CONFIG, $PROG, , $PATH)
-if [ test -z $EDB_CONFIG ]; then
-  echo $PROG  is not in your \$PATH. Please ensure it is.;
-  echo Read the manual page for you shell as to how to extend your path.;
-  echo FATAL ERROR. ABORT.;
-  exit -1;
-fi
-edb_cflags=`$EDB_CONFIG --cflags`
-edb_libs=`$EDB_CONFIG --libs`
-AC_SUBST(edb_cflags)
-AC_SUBST(edb_libs)
-
-PROG=ecore-config;
-AC_PATH_PROG(ECORE_CONFIG, $PROG, , $PATH)
-if [ test -z $ECORE_CONFIG ]; then
-  echo $PROG  is not in your \$PATH. Please ensure it is.;
-  echo Read the manual page for you shell as to how to extend your path.;
-  echo FATAL ERROR. ABORT.;
-  exit -1;
-fi
-ecore_cflags=`$ECORE_CONFIG --cflags`
-ecore_libs=`$ECORE_CONFIG --libs`
-AC_SUBST(ecore_cflags)
-AC_SUBST(ecore_libs)
+PKG_CHECK_MODULES(ENGY,
+  imlib2 = 1.4 edb = 0.9 evas = 0.9 ecore = 0.9 ecore-evas = 0.9)
 
 
 AC_CHECK_LIB(pthread,pthread_mutex_lock,pthread_libs=-lpthread,
Index: src/Makefile.am
===
RCS file: /cvs/e/e17/apps/engycad/src/Makefile.am,v
retrieving revision 1.1
diff -u -r1.1 Makefile.am
--- src/Makefile.am 8 Jul 2007 04:15:49 -   1.1
+++ src/Makefile.am 8 Jul 2007 07:37:23 -
@@ -2,7 +2,7 @@
 
 INCLUDES = \
-I../lib \
-   @imlib2_cflags@ @evas_cflags@ @edb_cflags@ @ecore_cflags@
+   @ENGY_CFLAGS@
 
 bin_PROGRAMS = engycad
 
@@ -75,4 +75,4 @@
 undo.c \
 undo.h
 
-engycad_LDADD = @imlib2_libs@ @evas_libs@ @pthread_libs@ @edb_libs@ 
@ecore_libs@ -lm -lc
+engycad_LDADD = @ENGY_LIBS@ -lm
Index: src/trans.c
===
RCS file: /cvs/e/e17/apps/engycad/src/trans.c,v
retrieving revision 1.1
diff -u -r1.1 trans.c
--- src/trans.c 8 Jul 2007 04:15:49 -   1.1
+++ src/trans.c 8 Jul 2007 07:37:23 -
@@ -21,6 +21,8 @@
  * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include math.h
+
 #include engy.h
 
 void
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Conf dialogs... modules?!

[Brian 'morlenxus' Miculcy]

I also suggest to have module categories, as we already use the
module.desktop files for the icons, we should use it for the categories.
This way we wouldn't have a long list, we instead have the modules more
organised in category lists.
It would be also cool to have the description directly in the
module.desktop, this way the module doesn't need to get loaded for
simply checking what the module does (with the about button).

Greets,
Brian 'morlenxus' Miculcy

On Sat, Jul 07, 2007 at 07:57:51PM -0500, Brian Mattern wrote:
 On Sun, Jul 08, 2007 at 01:40:37AM +0300, Hisham Mardam Bey wrote:
  On 7/7/07, Luchezar Petkov [EMAIL PROTECTED] wrote:
   Raster, why the heck are you doing this? I don't like the idea (and its 
   not
   only me, of course)... At least explain us :-)
  
  
  This is actually not a very bad idea, its actually a good move towards
  refactoring a lot of E's code and making it cleaner (if this continues
  with all the non-WM stuff in E that is).
  
  The only annoyance I can see here is having to load those modules
  yourself - which might be a bit of a problem to the clueless new user.
 
 I think they're on by default. Its just that there is no code to turn
 them on for old configs (nor should there be).
 
  
  I personally do advocate the idea though. The more important thing is
  to continue on doing this. 
 
 I agree. Pushing functionality into modules has a side effect of forcing
 the interfaces to be abstracted and (hopefully) cleaner. 
 
  E has become a BIG beast with a lot of
  features that are not required by a WM. What WM has so much
  configuration dialogs? X configs? Includes its own panels,
  mini-modules?  File manager?
  
  After thinking about the state of E (the WM / desktop shell first, and
  the entire EFL second), I believe that this is exactly what we need.
  We need to do this for everything that does not belong to the core WM.
  Things need to be moved out of the main code base and refactored.
  
  I even believe that we need to do this sort of thing for the desktop
  itself. E draws its own desktop, completely ignoring X's root window.
  Ignoring the root window itself is not a problem, but I firmly believe
  that we need to move the entire canvas desktop idea outside E. Call
  it e_desktop or whatever. E, as a WM, should not have to draw this
  desktop, handle the clock, battery, ibar, etc. and the rest of the
  modules that load and draw on the desktop. By putting this into E, not
  only have we made it bigger and slower, we have also made it more
  error and crash prone.
  
  The e_desktop application could, if need be, open up the space for
  modules like the ones we currently have. There is no reason for them
  to be a part of E itself. Now one would argue that some of those
  modules do in fact need access to some of the info that E has (ibox,
  drop shadow, pager?) but I am sure that we can find a sane way to do
  this stuff as well (I have not given those modules any thought as of
  now).
  
  Another part of E that really needs to move outside its code base is
  EFM. EFM is growing and becoming a terrifying beast. Anyone that has
  tried to fix something or add something to it knows that (ask me, I
  spent two hours understanding its code trying to add a feature the
  other day). Not only does EFM have its own process now, it keeps on
  growing and growing, and it still has a good way to go. We need to
  move EFM outside E and turn it into a standalone proper file manager.
  At that point,  E can *use* EFM for its file dialog needs, and having
  a file manager inside E as an excuse to needing a file selector /
  dialog for some internal things (background choosing, theme choosing
  etc) will no longer be a valid excuse to code a full fledged file
  manager inside E.
 
 Much of how the three components (wm, fm, desktop) interact would need
 to be re-thought. The IPC interfaces would need a LOT of work.  That
 said, the filemanager already does the majority of its work in a helper
 application. Anyway, I would like to hear from raster about the reasons
 behind mashing all of this functionality into one monolithic process
 before giving any more though to how it could be split up. :)
 
  
  Another component that should also be removed from E itself (maybe
  even completely deleted and replaced with an already existing library,
  or appended to that library) is e_thumb. e_thumb has no place inside E
  itself. We have Epsilon, a perfectly working library that can work
  both in library mode and in IPC mode as a service. If Epsilon has
  given some of us some trouble then we should fix it and use it instead
  of implementing a thumbnailer in E itself.
 
 
 I never did understand why epsilon was ignored. I know this was brought
 up at least on IRC years ago. The 'no deps' requirement here just
 resulted in much of the code in epsilon being rewritten inside e. 
 
 I'll leave the rest of this email for later (gotta run).
 
 rephorm.
 
 
 - End forwarded 

Re: [E-devel] compile patch for engycad

[Yuri]

2007/7/8, Vincent Torri [EMAIL PROTECTED]:

 Hey,

 here is a patch for the compilation of engy (no more *-config scripts are
 used now). I've also added math.h in a file
Thanks! That was an old configure.in


 Nevertheless, on my computer (core2 duo, so 64 bits), the program does not
 work. There are a lots of cast from a pointer to an int (from edb,
 mainly, but not all). Maybe that's why it does not work

Debug builds somehow breathe :) I'm trying to get it working with -O2 atm



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Conf dialogs... modules?!

[Luchezar Petkov]

Ok. Feeling a bit stupid... But, I'm convinced. After all, i just wanted a
few arguments. :-)

2007/7/8, Brian 'morlenxus' Miculcy [EMAIL PROTECTED]:

 I also suggest to have module categories, as we already use the
 module.desktop files for the icons, we should use it for the categories.
 This way we wouldn't have a long list, we instead have the modules more
 organised in category lists.
 It would be also cool to have the description directly in the
 module.desktop, this way the module doesn't need to get loaded for
 simply checking what the module does (with the about button).

 Greets,
 Brian 'morlenxus' Miculcy

 On Sat, Jul 07, 2007 at 07:57:51PM -0500, Brian Mattern wrote:
  On Sun, Jul 08, 2007 at 01:40:37AM +0300, Hisham Mardam Bey wrote:
   On 7/7/07, Luchezar Petkov [EMAIL PROTECTED] wrote:
Raster, why the heck are you doing this? I don't like the idea (and
 its not
only me, of course)... At least explain us :-)
   
  
   This is actually not a very bad idea, its actually a good move towards
   refactoring a lot of E's code and making it cleaner (if this continues
   with all the non-WM stuff in E that is).
  
   The only annoyance I can see here is having to load those modules
   yourself - which might be a bit of a problem to the clueless new user.
 
  I think they're on by default. Its just that there is no code to turn
  them on for old configs (nor should there be).
 
  
   I personally do advocate the idea though. The more important thing is
   to continue on doing this.
 
  I agree. Pushing functionality into modules has a side effect of forcing
  the interfaces to be abstracted and (hopefully) cleaner.
 
   E has become a BIG beast with a lot of
   features that are not required by a WM. What WM has so much
   configuration dialogs? X configs? Includes its own panels,
   mini-modules?  File manager?
  
   After thinking about the state of E (the WM / desktop shell first, and
   the entire EFL second), I believe that this is exactly what we need.
   We need to do this for everything that does not belong to the core WM.
   Things need to be moved out of the main code base and refactored.
  
   I even believe that we need to do this sort of thing for the desktop
   itself. E draws its own desktop, completely ignoring X's root window.
   Ignoring the root window itself is not a problem, but I firmly believe
   that we need to move the entire canvas desktop idea outside E. Call
   it e_desktop or whatever. E, as a WM, should not have to draw this
   desktop, handle the clock, battery, ibar, etc. and the rest of the
   modules that load and draw on the desktop. By putting this into E, not
   only have we made it bigger and slower, we have also made it more
   error and crash prone.
  
   The e_desktop application could, if need be, open up the space for
   modules like the ones we currently have. There is no reason for them
   to be a part of E itself. Now one would argue that some of those
   modules do in fact need access to some of the info that E has (ibox,
   drop shadow, pager?) but I am sure that we can find a sane way to do
   this stuff as well (I have not given those modules any thought as of
   now).
  
   Another part of E that really needs to move outside its code base is
   EFM. EFM is growing and becoming a terrifying beast. Anyone that has
   tried to fix something or add something to it knows that (ask me, I
   spent two hours understanding its code trying to add a feature the
   other day). Not only does EFM have its own process now, it keeps on
   growing and growing, and it still has a good way to go. We need to
   move EFM outside E and turn it into a standalone proper file manager.
   At that point,  E can *use* EFM for its file dialog needs, and having
   a file manager inside E as an excuse to needing a file selector /
   dialog for some internal things (background choosing, theme choosing
   etc) will no longer be a valid excuse to code a full fledged file
   manager inside E.
 
  Much of how the three components (wm, fm, desktop) interact would need
  to be re-thought. The IPC interfaces would need a LOT of work.  That
  said, the filemanager already does the majority of its work in a helper
  application. Anyway, I would like to hear from raster about the reasons
  behind mashing all of this functionality into one monolithic process
  before giving any more though to how it could be split up. :)
 
  
   Another component that should also be removed from E itself (maybe
   even completely deleted and replaced with an already existing library,
   or appended to that library) is e_thumb. e_thumb has no place inside E
   itself. We have Epsilon, a perfectly working library that can work
   both in library mode and in IPC mode as a service. If Epsilon has
   given some of us some trouble then we should fix it and use it instead
   of implementing a thumbnailer in E itself.
  
 
  I never did understand why epsilon was ignored. I know this was brought
  up at 

[E-devel] Is this a community project?

[Simon TRENY]

Hi guys,


Recent discussions about config dialogs being moved to modules leads me
to a question I've been asking myself quite often recently. I'm working
on the E-project for at least a couple of years now, and actually, I
still can't tell what is the scope of this project? How would you
define it?

Are we just working on a WM or are we trying to have a decent desktop
environment? If we are working on a WM, should it include a FM (well..
it seems so..), should it have its own toolkit (it seems so
too...)? Does it aim to be a WM for desktop configs or for embedded
devices? And if this project is about getting a nice desktop
environment, what apps should be part of it? What should be the point
in common of all these apps? Is using the EFL enough to be a part of
the environment? Or maybe we should have guidelines that all the apps
would have to respect (like the Gnome HIG)?!
I'm pretty sure that we can't find two devs with the exact same
definition of the project. We all see it differently!

In these conditions, how can we work together on this? If this a
one-man project, it's ok to share nothing.. But since it *tends* to be a
community project, we need to share ideas and to establish a common
project on which we all agree! If I could have known two years ago that
e17 would now have its own toolkit, its own FM, its config dialogs
moved to modules, shelves and a lot of other recent changes that I
don't necessarily agree with, I would probably have not spent so much
time on this project.. And I know I'm not the only dev feeling like
this right now... It would be nice if evolutions were discussed
publicly on the ML. For now, it just seems that when one dev wants a
new feature, he implements it without asking others what they think
about it. And most of these new features were not even in the TODO list
before...

Personally, I don't think I will ever commit any other code to this CVS
(on Etk mainly) if I don't feel the situation has changed (i.e. if we
don't have a precise roadmap and if we don't have defined precisely
the scope of the project). I'll probably just move Etk and other
projects I have in mind to another place. It's not a threat or
blackmail (anyway, I'm pretty sure most of the devs working on e17
don't even care about Etk...), I just don't see why I would share a CVS
with a project that I can't even define and that I can't even tell where
it is heading toward..


Regards,
Simon

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[Dr. Michael 'Mickey' Lauer]

(I hope you don't mind an outsiders view on the project...)

I have been following this project since 2002 and while I'm not so
much interested in a window manager (I'm into mobile embedded
systems), I have become more and more excited about your base libraries
(including Etk and Ewl).

Luckily I'm now in a position where I can decide on the ingredients of
a forthcoming mobile communications platform [1] and I'm actively
pushing EFL for that.

I'm really glad to see that E is getting more modular and that more
and more goodness gets moved into the base libraries for a broader
usage.

However I can understand of course that the base goal that put most of
you together was and still is a kick-ass window manager + desktop
environment. As long as this goal pushes the development of the base
libraries (which it did now for quite some years), I think you're
right on track...

[1] http://www.openmoko.org

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E CVS: proto mickeyl

[Dr. Michael 'Mickey' Lauer]

Vincent Torri wrote:
 no. It has been added intentionnaly. As I said in my commit message, it's
 to avoid a circular dependancy.

I see, ok, thanks.

 Please describe the error. It compiles, install and work fine on my 
 computer. Maybe I've forgotten to commit something.

Make: No rule to build pdf_thumbnailer.c

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E CVS: proto mickeyl

[Vincent Torri]

On Sun, 8 Jul 2007, Enlightenment CVS wrote:

 Log Message:
 epdf: make it build again by removing the plugin build (which is broken atm.).
 NB: It looks like this functionality has landed in epsilon anyway, so we might
 as well remove it completely.

no. It has been added intentionnaly. As I said in my commit message, it's 
to avoid a circular dependancy.

Please describe the error. It compiles, install and work fine on my 
computer. Maybe I've forgotten to commit something.

Vincent

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] exporting Epsilon_Plugin structure

[Vincent Torri]

Hey,

for the epsilon plugin of epdf, I need to export the Epsilon_Plugin. Can I 
move it from epsilon_plugin.h to Epsilon.h ?

Vincent

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [patch] e_shelf

[Laurent Ghigonis]

Hey !

Attached a patch for e_shelf that changes the behavior of
windows witch are moved on shelf unhide : 
it moves the windows just near the shelf, instead of moving them of the
shelf size offset.

Also fixed missing brackets.

If it seems ok, just tell me and i'll commit.

laurent? src/bin/e_shelf.patch
Index: src/bin/e_shelf.c
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_shelf.c,v
retrieving revision 1.68
diff -u -r1.68 e_shelf.c
--- src/bin/e_shelf.c	10 Jun 2007 11:01:41 -	1.68
+++ src/bin/e_shelf.c	8 Jul 2007 18:43:00 -
@@ -949,6 +949,8 @@
 	bd = l-data;
 	if ((bd-maximized  E_MAXIMIZE_TYPE) == E_MAXIMIZE_NONE)
 	  {
+	 int screen_w, screen_h;
+
 	 if (bd-lock_client_location)
 	   continue;
 	 if (es-hidden)
@@ -969,35 +971,40 @@
 	 if (!es-hidden)
 	   {
 		  if (!bd-shelf_fix.modified++)
-		bd-shelf_fix.x = bd-x;
-		bd-shelf_fix.y = bd-y;
+		{
+		   bd-shelf_fix.x = bd-x;
+		   bd-shelf_fix.y = bd-y;
+		}
 	   }
 
+ evas_output_viewport_get(bd-zone-container-bg_evas,
+	  NULL, NULL, screen_w, screen_h);
+
 	 switch (es-gadcon-orient)
 	   {
 		case E_GADCON_ORIENT_TOP:
 		case E_GADCON_ORIENT_CORNER_TL:
 		case E_GADCON_ORIENT_CORNER_TR:
 		   if (!es-hidden)
-		 e_border_move(bd, bd-x, bd-y + es-h);
+		 e_border_move(bd, bd-x, es-h);
 		   break;
 		case E_GADCON_ORIENT_BOTTOM:
 		case E_GADCON_ORIENT_CORNER_BL:
 		case E_GADCON_ORIENT_CORNER_BR:
 		   if (!es-hidden)
-		 e_border_move(bd, bd-x, bd-y - es-h);
+		 e_border_move(bd, bd-x, (screen_h - es-h) - bd-h);
 		   break;
 		case E_GADCON_ORIENT_LEFT:
 		case E_GADCON_ORIENT_CORNER_LB:
 		case E_GADCON_ORIENT_CORNER_LT:
 		   if (!es-hidden)
-		 e_border_move(bd, bd-x + es-w, bd-y);
+		 e_border_move(bd, es-w, bd-y);
 		   break; 
 		case E_GADCON_ORIENT_RIGHT:
 		case E_GADCON_ORIENT_CORNER_RB:
 		case E_GADCON_ORIENT_CORNER_RT:
 		   if (!es-hidden)
-		 e_border_move(bd, bd-x - es-w, bd-y);
+		 e_border_move(bd, (screen_w - es-w) - bd-w, bd-y);
 		   break; 
 		default:
 		   break;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] exporting Epsilon_Plugin structure

[Nathan Ingersoll]

I don't see a good reason not to.

On 7/8/07, Vincent Torri [EMAIL PROTECTED] wrote:

 Hey,

 for the epsilon plugin of epdf, I need to export the Epsilon_Plugin. Can I
 move it from epsilon_plugin.h to Epsilon.h ?

 Vincent

 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] engage_20070708 fails to build

[Didier Casse]

Hi All,
 Engage in current cvs fails to build and complains about a missing
*esmart*. Log attached. I believe engage has not been updated to the recent
changes.

--
With kind regards,
Didier.
+ umask 022
+ cd /home/didier/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/didier/rpmbuild/BUILD
+ rm -rf engage-0.0.9
+ /bin/gzip -dc /home/didier/rpmbuild/SOURCES/engage-0.0.9-20070708.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd engage-0.0.9
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
+ umask 022
+ cd /home/didier/rpmbuild/BUILD
+ cd engage-0.0.9
+ LANG=C
+ export LANG
+ unset DISPLAY
+ rm -rf missing
+ touch README
+ aclocal -I m4
+ autoheader
+ autoconf
+ libtoolize --copy --automake
+ automake --add-missing --copy --gnu
configure.in: installing `./install-sh'
configure.in: installing `./missing'
src/Makefile.am: installing `./compile'
src/Makefile.am: installing `./depcomp'
+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables'
+ export CFLAGS
+ CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables'
+ export CXXFLAGS
+ FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables'
+ export FFLAGS
++ find . -name config.guess -o -name config.sub
+ for i in '$(find . -name config.guess -o -name config.sub)'
++ basename ./config.guess
+ '[' -f /usr/lib/rpm/redhat/config.guess ']'
+ /bin/rm -f ./config.guess
++ basename ./config.guess
+ /bin/cp -fv /usr/lib/rpm/redhat/config.guess ./config.guess
+ for i in '$(find . -name config.guess -o -name config.sub)'
++ basename ./config.sub
+ '[' -f /usr/lib/rpm/redhat/config.sub ']'
+ /bin/rm -f ./config.sub
++ basename ./config.sub
+ /bin/cp -fv /usr/lib/rpm/redhat/config.sub ./config.sub
+ ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu 
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr 
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib 
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com 
--mandir=/usr/share/man --infodir=/usr/share/info
configure: error: Package requirements (
  esmart
  imlib2
  edje
  ecore
  ecore-config
  ecore-evas
  ecore-desktop
  evas
  etk
  embryo
) were not met:

No package 'esmart' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables ENGAGE_CFLAGS
and ENGAGE_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

error: Bad exit status from /var/tmp/rpm-tmp.43604 (%build)
Bad exit status from /var/tmp/rpm-tmp.43604 (%build)
aborting... engage.spec did not compile!

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] engage_20070708 fails to build

[Andreas Volz]

Am Sun, 8 Jul 2007 15:08:28 -0700 schrieb Didier Casse:

 Hi All,
   Engage in current cvs fails to build and complains about a
 missing *esmart*. Log attached. I believe engage has not been updated
 to the recent changes.

Hello,

where could I find engage in CVS?

regards
Andreas

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[Hisham Mardam Bey]

On 7/8/07, Simon TRENY [EMAIL PROTECTED] wrote:
 Hi guys,


 Recent discussions about config dialogs being moved to modules leads me
 to a question I've been asking myself quite often recently. I'm working
 on the E-project for at least a couple of years now, and actually, I
 still can't tell what is the scope of this project? How would you
 define it?


This is a question that needs to be answered both on this thread and
later made into a more formal goal on our website. We can not keep our
plans in our head and to ourselves.

 Are we just working on a WM or are we trying to have a decent desktop
 environment? If we are working on a WM, should it include a FM (well..
 it seems so..), should it have its own toolkit (it seems so
 too...)? Does it aim to be a WM for desktop configs or for embedded
 devices? And if this project is about getting a nice desktop
 environment, what apps should be part of it? What should be the point
 in common of all these apps? Is using the EFL enough to be a part of
 the environment? Or maybe we should have guidelines that all the apps
 would have to respect (like the Gnome HIG)?!
 I'm pretty sure that we can't find two devs with the exact same
 definition of the project. We all see it differently!

If we want to go to what we had in mind a few years ago, then E should
be a WM with a bit more functionality. The term used back then was
(and still is) desktop shell, What exactly is that? Thats a question
we need to answer. After several discussions with lots of developers,
I managed to find out that they are interested in a bit more than
that. They want to create a development platform that people can use
and rely on for personal computing applications and embedded
applications.

 In these conditions, how can we work together on this? If this a
 one-man project, it's ok to share nothing.. But since it *tends* to be a
 community project, we need to share ideas and to establish a common
 project on which we all agree! If I could have known two years ago that
 e17 would now have its own toolkit, its own FM, its config dialogs
 moved to modules, shelves and a lot of other recent changes that I
 don't necessarily agree with, I would probably have not spent so much
 time on this project.. And I know I'm not the only dev feeling like
 this right now... It would be nice if evolutions were discussed
 publicly on the ML. For now, it just seems that when one dev wants a
 new feature, he implements it without asking others what they think
 about it. And most of these new features were not even in the TODO list
 before...

This again boils down to the issue of having a clear goal for the
project in mind. The issue here is that saying what you want to
finally reach is not good enough. You need to be clear about how and
when you want to reach it. Any changes along the way need to be
brought up and discussed. I'm not saying we need to discuss
everything, but it would be nice (and helpful) to discuss the bigger
changes and plans that affect the entire project and its goal(s).

 Personally, I don't think I will ever commit any other code to this CVS
 (on Etk mainly) if I don't feel the situation has changed (i.e. if we
 don't have a precise roadmap and if we don't have defined precisely
 the scope of the project). I'll probably just move Etk and other
 projects I have in mind to another place. It's not a threat or
 blackmail (anyway, I'm pretty sure most of the devs working on e17
 don't even care about Etk...), I just don't see why I would share a CVS
 with a project that I can't even define and that I can't even tell where
 it is heading toward..

The more important point, aside all of this, that we *need* to
address, is that of decision making. We all know that raster (himself
included) is too busy to handle everything by himself. Patches take
ages to review, emails take ages to answer, decisions take a long time
as well. So, given that, what can we do about it? The way I see it, we
have several options.

One of the options would be to assign a maintainer to each piece of
code in our CVS. That maintainer should obviously know the code very
well and should be able to take a decision about a feature
improvement, an addition, a patch, a major redesign, and API break,
etc... When things have to do with that piece of code, anyone can
obviously pitch in, but it will be more or less his decision. If he is
too busy, that person can have a helper that is also knowledgeable
about that code and can take a decision. This should help the entire
lag we always have with emails, patches, features, etc. finding their
way into our CVS.

I personally think that this is one of the best ways to handle this
issue. Another way would be to simply discuss something on the mailing
list, and if the developer is knowledgeable about the code he is
working on, he can simply commit it if no one minds it. I would like
to go with the first option though. It is a much more structured and
organized approach.

Examples of the 

Re: [E-devel] Is this a community project?

[Виктор Кожухаров]

В пн, 2007-07-09 в 01:50 +0300, Hisham Mardam Bey написа:
 On 7/8/07, Simon TRENY [EMAIL PROTECTED] wrote:
  Hi guys,
 
 
  Recent discussions about config dialogs being moved to modules leads me
  to a question I've been asking myself quite often recently. I'm working
  on the E-project for at least a couple of years now, and actually, I
  still can't tell what is the scope of this project? How would you
  define it?
 
 
 This is a question that needs to be answered both on this thread and
 later made into a more formal goal on our website. We can not keep our
 plans in our head and to ourselves.
 
  Are we just working on a WM or are we trying to have a decent desktop
  environment? If we are working on a WM, should it include a FM (well..
  it seems so..), should it have its own toolkit (it seems so
  too...)? Does it aim to be a WM for desktop configs or for embedded
  devices? And if this project is about getting a nice desktop
  environment, what apps should be part of it? What should be the point
  in common of all these apps? Is using the EFL enough to be a part of
  the environment? Or maybe we should have guidelines that all the apps
  would have to respect (like the Gnome HIG)?!
  I'm pretty sure that we can't find two devs with the exact same
  definition of the project. We all see it differently!
 
 If we want to go to what we had in mind a few years ago, then E should
 be a WM with a bit more functionality. The term used back then was
 (and still is) desktop shell, What exactly is that? Thats a question
 we need to answer. After several discussions with lots of developers,
 I managed to find out that they are interested in a bit more than
 that. They want to create a development platform that people can use
 and rely on for personal computing applications and embedded
 applications.
Judging from the projects currently included into CVS, it seems that the
'Enlightenment' project has grown well past the 'desktop shell' stage.
While 'E' itself is currently a glorified WM, the whole 'Enlightenment'
project has all the ingredients to claim a 'desktop environment' title.
 
  In these conditions, how can we work together on this? If this a
  one-man project, it's ok to share nothing.. But since it *tends* to be a
  community project, we need to share ideas and to establish a common
  project on which we all agree! If I could have known two years ago that
  e17 would now have its own toolkit, its own FM, its config dialogs
  moved to modules, shelves and a lot of other recent changes that I
  don't necessarily agree with, I would probably have not spent so much
  time on this project.. And I know I'm not the only dev feeling like
  this right now... It would be nice if evolutions were discussed
  publicly on the ML. For now, it just seems that when one dev wants a
  new feature, he implements it without asking others what they think
  about it. And most of these new features were not even in the TODO list
  before...
 
 This again boils down to the issue of having a clear goal for the
 project in mind. The issue here is that saying what you want to
 finally reach is not good enough. You need to be clear about how and
 when you want to reach it. Any changes along the way need to be
 brought up and discussed. I'm not saying we need to discuss
 everything, but it would be nice (and helpful) to discuss the bigger
 changes and plans that affect the entire project and its goal(s).
 
  Personally, I don't think I will ever commit any other code to this CVS
  (on Etk mainly) if I don't feel the situation has changed (i.e. if we
  don't have a precise roadmap and if we don't have defined precisely
  the scope of the project). I'll probably just move Etk and other
  projects I have in mind to another place. It's not a threat or
  blackmail (anyway, I'm pretty sure most of the devs working on e17
  don't even care about Etk...), I just don't see why I would share a CVS
  with a project that I can't even define and that I can't even tell where
  it is heading toward..
 
 The more important point, aside all of this, that we *need* to
 address, is that of decision making. We all know that raster (himself
 included) is too busy to handle everything by himself. Patches take
 ages to review, emails take ages to answer, decisions take a long time
 as well. So, given that, what can we do about it? The way I see it, we
 have several options.
 
 One of the options would be to assign a maintainer to each piece of
 code in our CVS. That maintainer should obviously know the code very
 well and should be able to take a decision about a feature
 improvement, an addition, a patch, a major redesign, and API break,
 etc... When things have to do with that piece of code, anyone can
 obviously pitch in, but it will be more or less his decision. If he is
 too busy, that person can have a helper that is also knowledgeable
 about that code and can take a decision. This should help the entire
 lag we always have with emails, patches, 

Re: [E-devel] Is this a community project?

[dbpatterson]

Again, from an outsiders perspective, I thought it might be useful to  
pop in a word.

With regards to being just a WM or being a full desktop environment or  
being a desktop shell - you are well on your way to being a full  
desktop environment. with that said, I would not have signed up for  
this list if you weren't going in that direction - the libraries are  
what interests me most, in terms of what I like developing / want to  
develop in the future. the set of libraries is faster and higher  
quality than any other graphical libraries I've encountered - and  
speed, specifically the ability to run high quality software on very  
old / slow machines is indeed what first brought me (years and years  
ago) to linux.

so with regards to the expansion from just a WM to much more, as an  
outsider, I fully support it, and think it will draw more people to  
the project (assuming that is a good thing)

in terms of managing the codebase, having all changes go through the  
mailing lists would be especially helpful to new people, in terms of  
getting to know the code, and also keeping on top of new things  
happening. time is precious, as mentioned, and having emails that you  
can get to whenever is much easier than having to be on IRC at certain  
times

beyond that, as my first post to this mailing list, I do want to  
commend all the work that has been done so far, it is really quite  
impressive; secondly, (and this is a purely selfish request) in what  
library / place would you reccommend I start digging. I understand on  
a theoretical basis how the libraries work (from reading docs) but  
that's not the same as actually knowing the code...so, ecore? or e  
itself?  or is the bug tracker operational (so I could go and try to  
hunt down bugs, which always seems a good way to start).

Thanks,
Daniel

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[Hisham Mardam Bey]

On 7/9/07, Виктор Кожухаров [EMAIL PROTECTED] wrote:
 
  One of the options would be to assign a maintainer to each piece of
  code in our CVS. That maintainer should obviously know the code very
  well and should be able to take a decision about a feature
  improvement, an addition, a patch, a major redesign, and API break,
  etc... When things have to do with that piece of code, anyone can
  obviously pitch in, but it will be more or less his decision. If he is
  too busy, that person can have a helper that is also knowledgeable
  about that code and can take a decision. This should help the entire
  lag we always have with emails, patches, features, etc. finding their
  way into our CVS.

 My personal view is that dedicated maintainers might be a bit overkill
 at this point. Once projects are finally released, then a dedicated
 maintainer is really justified. But the current code base is constantly
 changing, even if not as drastically as it used to. Furthermore,
 maintainers can never be truly 'dedicated', mainly because of the spare
 time issue. And we all know that spare time is hart to come by, even
 sometimes impossible to obtain.

 An intermediate solution would be to discuss any changes on the dev
 mailing list. And by discussing, I don't mean that the proposer should
 post a message, which will be ignored, but people should actually try
 and participate. Furthermore, we should really stick with discussing
 important issues in the dev list, instead of on irc. Mainly, because
 theres a centralized 'log' of the discussions going on here, and there
 is no excuse for someone missing a conversation. I myself have made the
 terrible mistake of discussing changes on irc only, thus keeping
 interested people out of the loop.

The point here is that leaving things open-ended doesnt always get the
job done. If someone wants to work on (for example) Etk, Exhibit,
Evolve, or any related app / libs, I will help them out (and in
reality, only those directly involved with the aforementioned will
help them out).

The question here is though, what do we do when it comes to things
like Ecore, Evas, and Edje? Who takes the decisions there? Raster is
obviously too busy, others dont really know enough about the
internals, so what do we do? (Note that some people DO know enough
about the internals of those libs, so they need to be handed the
responsibility, if they choose to accept it).

The question that I will ask again is, why do we have patches that
are several months old on our mailing list that have not been given a
yes or no yet?.

 At this stage of development, API breakages should not be a concern. As
 you said, there have been no 'stable' releases yet, so we can't really
 piss off users of the libraries, as they should be bloody aware that the
 code is unstable. Internal breaks can easily be fixed, thanks
 to /insert_your_diety_here/'s great inventions, find and grep.

Indeed, and the more important issue is that after we *do* release,
will we THEN want to break the API? Thats going to be even more
painful, not to mention will make our libraries obsolete to who ever
decided to use them (just when these guys went ahead and released
something, they're breaking it or creating a second version of it - is
what people are gonna think).

Regards,

hisham.

-- 
Hisham Mardam Bey
http://hisham.cc/
+9613609386
Codito Ergo Sum (I Code Therefore I Am)
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[The Rasterman]

On Mon, 9 Jul 2007 01:50:44 +0300 Hisham Mardam Bey
[EMAIL PROTECTED] babbled:

Simon - I know your mail has been lingering in my inbox for a while - but since
it's out here...

 On 7/8/07, Simon TRENY [EMAIL PROTECTED] wrote:
  Hi guys,
 
 
  Recent discussions about config dialogs being moved to modules leads me
  to a question I've been asking myself quite often recently. I'm working
  on the E-project for at least a couple of years now, and actually, I
  still can't tell what is the scope of this project? How would you
  define it?
 
 
 This is a question that needs to be answered both on this thread and
 later made into a more formal goal on our website. We can not keep our
 plans in our head and to ourselves.
 
  Are we just working on a WM or are we trying to have a decent desktop
  environment? If we are working on a WM, should it include a FM (well..
  it seems so..), should it have its own toolkit (it seems so
  too...)? Does it aim to be a WM for desktop configs or for embedded
  devices? And if this project is about getting a nice desktop
  environment, what apps should be part of it? What should be the point
  in common of all these apps? Is using the EFL enough to be a part of
  the environment? Or maybe we should have guidelines that all the apps
  would have to respect (like the Gnome HIG)?!
  I'm pretty sure that we can't find two devs with the exact same
  definition of the project. We all see it differently!
 
 If we want to go to what we had in mind a few years ago, then E should
 be a WM with a bit more functionality. The term used back then was
 (and still is) desktop shell, What exactly is that? Thats a question
 we need to answer. After several discussions with lots of developers,
 I managed to find out that they are interested in a bit more than
 that. They want to create a development platform that people can use
 and rely on for personal computing applications and embedded
 applications.

On a personal level - My goals STILL is to create a WM - a flexible one with
extra features (the desktop shell) enough to launch what apps you need/want,
manage them, access your files and configure your basic system/UI (that E can
control). Creating libraries along the way to get there is a bi-product. I want
the libs and apps to scale from low-end to high end (and that does imply
embedded systems these days).

But in doing this this opens up a whole host of new mini-projects which, IMHO
should have a life of their own and do whatever the authors want them to do.
The reason for this is that I'd like to keep control decentralised.

I would prefer that we keep our goals small and realistic - something we can
achieve in a reasonable time-frame. A whole desktop environment is a huge
undertaking if you want to be on-par with others calling themselves that. If we
aim for less, we can get there, then of course reach out further if
needed/wanted. IMHO aiming for a desktop shell is doable - for a WM. Aiming for
being able to do all that is needed for embedded devices is doable as it's a
more limited problem space than the desktop in general as it mostly means
building lots of mechanism and ability, with flair and style, rather than
massive incredibly full featured apps.

  In these conditions, how can we work together on this? If this a
  one-man project, it's ok to share nothing.. But since it *tends* to be a
  community project, we need to share ideas and to establish a common
  project on which we all agree! If I could have known two years ago that
  e17 would now have its own toolkit, its own FM, its config dialogs
  moved to modules, shelves and a lot of other recent changes that I
  don't necessarily agree with, I would probably have not spent so much
  time on this project.. And I know I'm not the only dev feeling like
  this right now... It would be nice if evolutions were discussed
  publicly on the ML. For now, it just seems that when one dev wants a
  new feature, he implements it without asking others what they think
  about it. And most of these new features were not even in the TODO list
  before...
 
 This again boils down to the issue of having a clear goal for the
 project in mind. The issue here is that saying what you want to
 finally reach is not good enough. You need to be clear about how and
 when you want to reach it. Any changes along the way need to be
 brought up and discussed. I'm not saying we need to discuss
 everything, but it would be nice (and helpful) to discuss the bigger
 changes and plans that affect the entire project and its goal(s).

I wish I had time for more discussion. Though frankly - if I discussed
everything I did - I would be doing nothing. You may have noticed how little
e-mail I keep up with these days.

  Personally, I don't think I will ever commit any other code to this CVS
  (on Etk mainly) if I don't feel the situation has changed (i.e. if we
  don't have a precise roadmap and if we don't have defined precisely
  the scope of the project). I'll 

Re: [E-devel] Is this a community project?

[Hisham Mardam Bey]

On 7/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Again, from an outsiders perspective, I thought it might be useful to
 pop in a word.

 With regards to being just a WM or being a full desktop environment or
 being a desktop shell - you are well on your way to being a full
 desktop environment. with that said, I would not have signed up for
 this list if you weren't going in that direction - the libraries are
 what interests me most, in terms of what I like developing / want to
 develop in the future. the set of libraries is faster and higher
 quality than any other graphical libraries I've encountered - and
 speed, specifically the ability to run high quality software on very
 old / slow machines is indeed what first brought me (years and years
 ago) to linux.

This is yet another example of how a lot of users (developers
actually) are interested in the EFL as a development platform. Since
we are seeing this quite often these days, why arent we, as the core
EFL developers, doing anything about it to make their life (and their
adoption of our work) easier? This is yet another reason to have
better task delegation.

 so with regards to the expansion from just a WM to much more, as an
 outsider, I fully support it, and think it will draw more people to
 the project (assuming that is a good thing)

 in terms of managing the codebase, having all changes go through the
 mailing lists would be especially helpful to new people, in terms of
 getting to know the code, and also keeping on top of new things
 happening. time is precious, as mentioned, and having emails that you
 can get to whenever is much easier than having to be on IRC at certain
 times

 beyond that, as my first post to this mailing list, I do want to
 commend all the work that has been done so far, it is really quite
 impressive; secondly, (and this is a purely selfish request) in what
 library / place would you reccommend I start digging. I understand on
 a theoretical basis how the libraries work (from reading docs) but
 that's not the same as actually knowing the code...so, ecore? or e
 itself?  or is the bug tracker operational (so I could go and try to
 hunt down bugs, which always seems a good way to start).

I think this needs to be moved to its own thread Daniel (=


-- 
Hisham Mardam Bey
http://hisham.cc/
+9613609386
Codito Ergo Sum (I Code Therefore I Am)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[dan sinclair]

On 8-Jul-07, at 7:40 PM, Hisham Mardam Bey wrote:

 On 7/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Again, from an outsiders perspective, I thought it might be useful to
 pop in a word.

 With regards to being just a WM or being a full desktop  
 environment or
 being a desktop shell - you are well on your way to being a full
 desktop environment. with that said, I would not have signed up for
 this list if you weren't going in that direction - the libraries are
 what interests me most, in terms of what I like developing / want to
 develop in the future. the set of libraries is faster and higher
 quality than any other graphical libraries I've encountered - and
 speed, specifically the ability to run high quality software on very
 old / slow machines is indeed what first brought me (years and years
 ago) to linux.

 This is yet another example of how a lot of users (developers
 actually) are interested in the EFL as a development platform. Since
 we are seeing this quite often these days, why arent we, as the core
 EFL developers, doing anything about it to make their life (and their
 adoption of our work) easier? This is yet another reason to have
 better task delegation.


How can anyone possibly do this without causing issues? Do we push  
them to Ewl? Well the Etk folks will yell. Do we push them to  
straight Evas/Edje? You're making their life harder to start with.  
The project is too fragmented unless the person steps up and says  
what they _want_ to work on.

We've already started setting up places for them to get the  
information they need. We have wiki.enlightenment.org, which as a lot  
of Edje coding information in it along with a lot of Ewl information.  
There is the e17 todo list for e17 things to be done.  
bugs.enlightenment.org has a lot of Ewl work that needs to be done.  
docs.enlightenment.org has all of the API docs built nightly and the  
cvs books copied over.

The information is there if people want to start working on things.

dan


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[dan sinclair]

On 8-Jul-07, at 7:35 PM, Hisham Mardam Bey wrote:

 The question that I will ask again is, why do we have patches that
 are several months old on our mailing list that have not been given a
 yes or no yet?.


Probably because they got lost in a flood of email and the author  
never popped up to ask what's going on with their patches.

dan



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[The Rasterman]

On Mon, 9 Jul 2007 02:35:15 +0300 Hisham Mardam Bey
[EMAIL PROTECTED] babbled:

 On 7/9/07, Виктор Кожухаров [EMAIL PROTECTED] wrote:
  
   One of the options would be to assign a maintainer to each piece of
   code in our CVS. That maintainer should obviously know the code very
   well and should be able to take a decision about a feature
   improvement, an addition, a patch, a major redesign, and API break,
   etc... When things have to do with that piece of code, anyone can
   obviously pitch in, but it will be more or less his decision. If he is
   too busy, that person can have a helper that is also knowledgeable
   about that code and can take a decision. This should help the entire
   lag we always have with emails, patches, features, etc. finding their
   way into our CVS.
 
  My personal view is that dedicated maintainers might be a bit overkill
  at this point. Once projects are finally released, then a dedicated
  maintainer is really justified. But the current code base is constantly
  changing, even if not as drastically as it used to. Furthermore,
  maintainers can never be truly 'dedicated', mainly because of the spare
  time issue. And we all know that spare time is hart to come by, even
  sometimes impossible to obtain.
 
  An intermediate solution would be to discuss any changes on the dev
  mailing list. And by discussing, I don't mean that the proposer should
  post a message, which will be ignored, but people should actually try
  and participate. Furthermore, we should really stick with discussing
  important issues in the dev list, instead of on irc. Mainly, because
  theres a centralized 'log' of the discussions going on here, and there
  is no excuse for someone missing a conversation. I myself have made the
  terrible mistake of discussing changes on irc only, thus keeping
  interested people out of the loop.
 
 The point here is that leaving things open-ended doesnt always get the
 job done. If someone wants to work on (for example) Etk, Exhibit,
 Evolve, or any related app / libs, I will help them out (and in
 reality, only those directly involved with the aforementioned will
 help them out).
 
 The question here is though, what do we do when it comes to things
 like Ecore, Evas, and Edje? Who takes the decisions there? Raster is
 obviously too busy, others dont really know enough about the
 internals, so what do we do? (Note that some people DO know enough
 about the internals of those libs, so they need to be handed the
 responsibility, if they choose to accept it).
 
 The question that I will ask again is, why do we have patches that
 are several months old on our mailing list that have not been given a
 yes or no yet?.

i swear i recently cleaned out the patches - like a few weeks back?
Actually.. .I think we need a patches mailing list...?

  At this stage of development, API breakages should not be a concern. As
  you said, there have been no 'stable' releases yet, so we can't really
  piss off users of the libraries, as they should be bloody aware that the
  code is unstable. Internal breaks can easily be fixed, thanks
  to /insert_your_diety_here/'s great inventions, find and grep.
 
 Indeed, and the more important issue is that after we *do* release,
 will we THEN want to break the API? Thats going to be even more
 painful, not to mention will make our libraries obsolete to who ever
 decided to use them (just when these guys went ahead and released
 something, they're breaking it or creating a second version of it - is
 what people are gonna think).
 
 Regards,
 
 hisham.
 
 -- 
 Hisham Mardam Bey
 http://hisham.cc/
 +9613609386
 Codito Ergo Sum (I Code Therefore I Am)
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[The Rasterman]

On Sun, 08 Jul 2007 16:32:31 -0700 [EMAIL PROTECTED] babbled:

 Again, from an outsiders perspective, I thought it might be useful to  
 pop in a word.
 
 With regards to being just a WM or being a full desktop environment or  
 being a desktop shell - you are well on your way to being a full  
 desktop environment. with that said, I would not have signed up for  
 this list if you weren't going in that direction - the libraries are  
 what interests me most, in terms of what I like developing / want to  
 develop in the future. the set of libraries is faster and higher  
 quality than any other graphical libraries I've encountered - and  
 speed, specifically the ability to run high quality software on very  
 old / slow machines is indeed what first brought me (years and years  
 ago) to linux.

:)

 so with regards to the expansion from just a WM to much more, as an  
 outsider, I fully support it, and think it will draw more people to  
 the project (assuming that is a good thing)
 
 in terms of managing the codebase, having all changes go through the  
 mailing lists would be especially helpful to new people, in terms of  
 getting to know the code, and also keeping on top of new things  
 happening. time is precious, as mentioned, and having emails that you  
 can get to whenever is much easier than having to be on IRC at certain  
 times

OK - I need to pipe up here. Yes - email is good. it's logged and archived and
accessible. It has one BIG BIG BIG BIG drawback. It SLOWS DISCUSSION DOWN TO A
CRAWL. Tod discuss on email can take days or weeks. To do it on IRC takes
minutes or hours. I admit I have been really guilty of this lately. But I guess
it's in response to basically having my time so squeezed that It's either
discuss on email and NEVER DO ANYTHING or blip on IRC for things I'm uncertain
of and otherwise DO as much as I can.

Now let's beware of just saying email is the answer (and web forums are not
an answer either - it's the same as e-mail).

Maybe we need to have official IRC logs? Maybe add a #ecode channel whose ONLY
purpose is discussion of code, design, direction ideas etc. No help questions -
no random discussion. Log it and put that up on-line. If you want to pipe up as
part of the discussion - join the channel. People who have been away/asleep can
catch up by reading the logs. I am NOT saying we get rid of Email or don't
use it, but I am trying to find a better way to do this...

 beyond that, as my first post to this mailing list, I do want to  
 commend all the work that has been done so far, it is really quite  
 impressive; secondly, (and this is a purely selfish request) in what  
 library / place would you reccommend I start digging. I understand on  
 a theoretical basis how the libraries work (from reading docs) but  
 that's not the same as actually knowing the code...so, ecore? or e  
 itself?  or is the bug tracker operational (so I could go and try to  
 hunt down bugs, which always seems a good way to start).

bug tracker is active - with a possible move to bugzilla on the table after
some use for the current one (yet another thread in my inbox i have marked to
respond to - along with dozens of others still waiting).

 Thanks,
 Daniel
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[dan sinclair]

On 8-Jul-07, at 7:43 PM, Carsten Haitzler (The Rasterman) wrote:

 On Mon, 9 Jul 2007 02:35:15 +0300 Hisham Mardam Bey
 [EMAIL PROTECTED] babbled:

 On 7/9/07, Виктор Кожухаров [EMAIL PROTECTED]  
 wrote:

 One of the options would be to assign a maintainer to each piece of
 code in our CVS. That maintainer should obviously know the code  
 very
 well and should be able to take a decision about a feature
 improvement, an addition, a patch, a major redesign, and API break,
 etc... When things have to do with that piece of code, anyone can
 obviously pitch in, but it will be more or less his decision. If  
 he is
 too busy, that person can have a helper that is also  
 knowledgeable
 about that code and can take a decision. This should help the  
 entire
 lag we always have with emails, patches, features, etc. finding  
 their
 way into our CVS.

 My personal view is that dedicated maintainers might be a bit  
 overkill
 at this point. Once projects are finally released, then a dedicated
 maintainer is really justified. But the current code base is  
 constantly
 changing, even if not as drastically as it used to. Furthermore,
 maintainers can never be truly 'dedicated', mainly because of the  
 spare
 time issue. And we all know that spare time is hart to come by, even
 sometimes impossible to obtain.

 An intermediate solution would be to discuss any changes on the dev
 mailing list. And by discussing, I don't mean that the proposer  
 should
 post a message, which will be ignored, but people should actually  
 try
 and participate. Furthermore, we should really stick with discussing
 important issues in the dev list, instead of on irc. Mainly, because
 theres a centralized 'log' of the discussions going on here, and  
 there
 is no excuse for someone missing a conversation. I myself have  
 made the
 terrible mistake of discussing changes on irc only, thus keeping
 interested people out of the loop.

 The point here is that leaving things open-ended doesnt always get  
 the
 job done. If someone wants to work on (for example) Etk, Exhibit,
 Evolve, or any related app / libs, I will help them out (and in
 reality, only those directly involved with the aforementioned will
 help them out).

 The question here is though, what do we do when it comes to things
 like Ecore, Evas, and Edje? Who takes the decisions there? Raster is
 obviously too busy, others dont really know enough about the
 internals, so what do we do? (Note that some people DO know enough
 about the internals of those libs, so they need to be handed the
 responsibility, if they choose to accept it).

 The question that I will ask again is, why do we have patches that
 are several months old on our mailing list that have not been given a
 yes or no yet?.

 i swear i recently cleaned out the patches - like a few weeks back?
 Actually.. .I think we need a patches mailing list...?

Can you say bugzilla? It makes it really easy to deal with patches  
and let the submitter update them and add comments all in one place.  
You could also probably get it setup to email a list with bug changes  
if you wanted.

dan


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[The Rasterman]

On Sun, 8 Jul 2007 19:55:08 -0400 dan sinclair [EMAIL PROTECTED] babbled:

 
 On 8-Jul-07, at 7:43 PM, Carsten Haitzler (The Rasterman) wrote:
 
  On Mon, 9 Jul 2007 02:35:15 +0300 Hisham Mardam Bey
  [EMAIL PROTECTED] babbled:
 
  On 7/9/07, Виктор Кожухаров [EMAIL PROTECTED]  
  wrote:
 
  One of the options would be to assign a maintainer to each piece of
  code in our CVS. That maintainer should obviously know the code  
  very
  well and should be able to take a decision about a feature
  improvement, an addition, a patch, a major redesign, and API break,
  etc... When things have to do with that piece of code, anyone can
  obviously pitch in, but it will be more or less his decision. If  
  he is
  too busy, that person can have a helper that is also  
  knowledgeable
  about that code and can take a decision. This should help the  
  entire
  lag we always have with emails, patches, features, etc. finding  
  their
  way into our CVS.
 
  My personal view is that dedicated maintainers might be a bit  
  overkill
  at this point. Once projects are finally released, then a dedicated
  maintainer is really justified. But the current code base is  
  constantly
  changing, even if not as drastically as it used to. Furthermore,
  maintainers can never be truly 'dedicated', mainly because of the  
  spare
  time issue. And we all know that spare time is hart to come by, even
  sometimes impossible to obtain.
 
  An intermediate solution would be to discuss any changes on the dev
  mailing list. And by discussing, I don't mean that the proposer  
  should
  post a message, which will be ignored, but people should actually  
  try
  and participate. Furthermore, we should really stick with discussing
  important issues in the dev list, instead of on irc. Mainly, because
  theres a centralized 'log' of the discussions going on here, and  
  there
  is no excuse for someone missing a conversation. I myself have  
  made the
  terrible mistake of discussing changes on irc only, thus keeping
  interested people out of the loop.
 
  The point here is that leaving things open-ended doesnt always get  
  the
  job done. If someone wants to work on (for example) Etk, Exhibit,
  Evolve, or any related app / libs, I will help them out (and in
  reality, only those directly involved with the aforementioned will
  help them out).
 
  The question here is though, what do we do when it comes to things
  like Ecore, Evas, and Edje? Who takes the decisions there? Raster is
  obviously too busy, others dont really know enough about the
  internals, so what do we do? (Note that some people DO know enough
  about the internals of those libs, so they need to be handed the
  responsibility, if they choose to accept it).
 
  The question that I will ask again is, why do we have patches that
  are several months old on our mailing list that have not been given a
  yes or no yet?.
 
  i swear i recently cleaned out the patches - like a few weeks back?
  Actually.. .I think we need a patches mailing list...?
 
 Can you say bugzilla? It makes it really easy to deal with patches  
 and let the submitter update them and add comments all in one place.  
 You could also probably get it setup to email a list with bug changes  
 if you wanted.

Can we set up a bugzilla project (per e project) SPECIFICALLY for patches?
(separate it from bug reports)?

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[dan sinclair]

On 8-Jul-07, at 7:59 PM, Carsten Haitzler (The Rasterman) wrote:

 On Sun, 8 Jul 2007 19:55:08 -0400 dan sinclair  
 [EMAIL PROTECTED] babbled:


 i swear i recently cleaned out the patches - like a few weeks back?
 Actually.. .I think we need a patches mailing list...?

 Can you say bugzilla? It makes it really easy to deal with patches
 and let the submitter update them and add comments all in one place.
 You could also probably get it setup to email a list with bug changes
 if you wanted.

 Can we set up a bugzilla project (per e project) SPECIFICALLY for  
 patches?
 (separate it from bug reports)?


Hm, you can setup products and components of those products. So, each  
e project could be added with a single component Patch or something.  
The severity's are the same for all projects so we can't change that  
as we need to full list of severity's for Ewl.

Or, alternatively, you could setup an E17 Patches project if you  
wanted. Thought, I think it would be better to keep it so it _could_  
have more components added later if we wanted to track more stuff per  
project.

dan


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[dan sinclair]

On 8-Jul-07, at 7:51 PM, Carsten Haitzler (The Rasterman) wrote:

 Maybe we need to have official IRC logs? Maybe add a #ecode channel  
 whose ONLY
 purpose is discussion of code, design, direction ideas etc. No help  
 questions -
 no random discussion. Log it and put that up on-line. If you want  
 to pipe up as
 part of the discussion - join the channel. People who have been  
 away/asleep can
 catch up by reading the logs. I am NOT saying we get rid of Email  
 or don't
 use it, but I am trying to find a better way to do this...


Isn't this what #edevelop was for originally? Couldn't we just  
enforce the topic in there and let all off-topic stuff go elsewhere  
(#e or some other channel).

I think allowing coding questions is valid as that can point out  
flaws in your API design or things that you've missed all together.  
It's a hard line to draw.

dan


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Is this a community project?

[Hisham Mardam Bey]

On 7/9/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
 On Mon, 9 Jul 2007 01:50:44 +0300 Hisham Mardam Bey
 [EMAIL PROTECTED] babbled:

 Simon - I know your mail has been lingering in my inbox for a while - but 
 since
 it's out here...

  On 7/8/07, Simon TRENY [EMAIL PROTECTED] wrote:
   Hi guys,
  
  
   Recent discussions about config dialogs being moved to modules leads me
   to a question I've been asking myself quite often recently. I'm working
   on the E-project for at least a couple of years now, and actually, I
   still can't tell what is the scope of this project? How would you
   define it?
  
 
  This is a question that needs to be answered both on this thread and
  later made into a more formal goal on our website. We can not keep our
  plans in our head and to ourselves.
 
   Are we just working on a WM or are we trying to have a decent desktop
   environment? If we are working on a WM, should it include a FM (well..
   it seems so..), should it have its own toolkit (it seems so
   too...)? Does it aim to be a WM for desktop configs or for embedded
   devices? And if this project is about getting a nice desktop
   environment, what apps should be part of it? What should be the point
   in common of all these apps? Is using the EFL enough to be a part of
   the environment? Or maybe we should have guidelines that all the apps
   would have to respect (like the Gnome HIG)?!
   I'm pretty sure that we can't find two devs with the exact same
   definition of the project. We all see it differently!
 
  If we want to go to what we had in mind a few years ago, then E should
  be a WM with a bit more functionality. The term used back then was
  (and still is) desktop shell, What exactly is that? Thats a question
  we need to answer. After several discussions with lots of developers,
  I managed to find out that they are interested in a bit more than
  that. They want to create a development platform that people can use
  and rely on for personal computing applications and embedded
  applications.

 On a personal level - My goals STILL is to create a WM - a flexible one with
 extra features (the desktop shell) enough to launch what apps you need/want,
 manage them, access your files and configure your basic system/UI (that E can
 control). Creating libraries along the way to get there is a bi-product. I 
 want
 the libs and apps to scale from low-end to high end (and that does imply
 embedded systems these days).

 But in doing this this opens up a whole host of new mini-projects which, 
 IMHO
 should have a life of their own and do whatever the authors want them to do.
 The reason for this is that I'd like to keep control decentralised.

 I would prefer that we keep our goals small and realistic - something we can
 achieve in a reasonable time-frame. A whole desktop environment is a huge
 undertaking if you want to be on-par with others calling themselves that. If 
 we
 aim for less, we can get there, then of course reach out further if
 needed/wanted. IMHO aiming for a desktop shell is doable - for a WM. Aiming 
 for
 being able to do all that is needed for embedded devices is doable as it's a
 more limited problem space than the desktop in general as it mostly means
 building lots of mechanism and ability, with flair and style, rather than
 massive incredibly full featured apps.

   In these conditions, how can we work together on this? If this a
   one-man project, it's ok to share nothing.. But since it *tends* to be a
   community project, we need to share ideas and to establish a common
   project on which we all agree! If I could have known two years ago that
   e17 would now have its own toolkit, its own FM, its config dialogs
   moved to modules, shelves and a lot of other recent changes that I
   don't necessarily agree with, I would probably have not spent so much
   time on this project.. And I know I'm not the only dev feeling like
   this right now... It would be nice if evolutions were discussed
   publicly on the ML. For now, it just seems that when one dev wants a
   new feature, he implements it without asking others what they think
   about it. And most of these new features were not even in the TODO list
   before...
 
  This again boils down to the issue of having a clear goal for the
  project in mind. The issue here is that saying what you want to
  finally reach is not good enough. You need to be clear about how and
  when you want to reach it. Any changes along the way need to be
  brought up and discussed. I'm not saying we need to discuss
  everything, but it would be nice (and helpful) to discuss the bigger
  changes and plans that affect the entire project and its goal(s).

 I wish I had time for more discussion. Though frankly - if I discussed
 everything I did - I would be doing nothing. You may have noticed how little
 e-mail I keep up with these days.

   Personally, I don't think I will ever commit any other code to this CVS
   (on Etk mainly) if I 

Re: [E-devel] Is this a community project?

[Gustavo Sverzut Barbieri]

On 7/8/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
 On Mon, 9 Jul 2007 02:35:15 +0300 Hisham Mardam Bey
 [EMAIL PROTECTED] babbled:

  On 7/9/07, Виктор Кожухаров [EMAIL PROTECTED] wrote:
   
One of the options would be to assign a maintainer to each piece of
code in our CVS. That maintainer should obviously know the code very
well and should be able to take a decision about a feature
improvement, an addition, a patch, a major redesign, and API break,
etc... When things have to do with that piece of code, anyone can
obviously pitch in, but it will be more or less his decision. If he is
too busy, that person can have a helper that is also knowledgeable
about that code and can take a decision. This should help the entire
lag we always have with emails, patches, features, etc. finding their
way into our CVS.
 
   My personal view is that dedicated maintainers might be a bit overkill
   at this point. Once projects are finally released, then a dedicated
   maintainer is really justified. But the current code base is constantly
   changing, even if not as drastically as it used to. Furthermore,
   maintainers can never be truly 'dedicated', mainly because of the spare
   time issue. And we all know that spare time is hart to come by, even
   sometimes impossible to obtain.
  
   An intermediate solution would be to discuss any changes on the dev
   mailing list. And by discussing, I don't mean that the proposer should
   post a message, which will be ignored, but people should actually try
   and participate. Furthermore, we should really stick with discussing
   important issues in the dev list, instead of on irc. Mainly, because
   theres a centralized 'log' of the discussions going on here, and there
   is no excuse for someone missing a conversation. I myself have made the
   terrible mistake of discussing changes on irc only, thus keeping
   interested people out of the loop.
 
  The point here is that leaving things open-ended doesnt always get the
  job done. If someone wants to work on (for example) Etk, Exhibit,
  Evolve, or any related app / libs, I will help them out (and in
  reality, only those directly involved with the aforementioned will
  help them out).
 
  The question here is though, what do we do when it comes to things
  like Ecore, Evas, and Edje? Who takes the decisions there? Raster is
  obviously too busy, others dont really know enough about the
  internals, so what do we do? (Note that some people DO know enough
  about the internals of those libs, so they need to be handed the
  responsibility, if they choose to accept it).
 
  The question that I will ask again is, why do we have patches that
  are several months old on our mailing list that have not been given a
  yes or no yet?.

 i swear i recently cleaned out the patches - like a few weeks back?
 Actually.. .I think we need a patches mailing list...?

Maybe use patchwork? http://ozlabs.org/~jk/projects/patchwork/

It's a crawler of patches in some mail list, then you can browse it
and get those easily.

-- 
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
   MSN: [EMAIL PROTECTED]
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] {Spam?} Re: Is this a community project?

[Vincent Torri]

On Mon, 9 Jul 2007, Carsten Haitzler (The Rasterman) wrote:

 i swear i recently cleaned out the patches - like a few weeks back?
 Actually.. .I think we need a patches mailing list...?

bugzilla [1] is a good way to save patches, and to report bugs. No need 
for another ML.

Bugzilla is also a good way to save propositions about API. I'm working on 
several projects that are using bugzilla and I think that it is far better 
than having patches in some mail. You can assign a person to review that 
bug/patch, you can define a priority (so that, when asparagus time comes, 
you can have a look at all the bugs/patches you want to be fixed/applied), 
etc...

Vincent

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel