Re: [E-devel] Re: [e-users] E laggy?

2005-11-02 Thread Michael Jennings 
On Thursday, 03 November 2005, at 14:27:19 (+0900),
Carsten Haitzler wrote:

> efence is a memory overrun checker. dmalloc doesnt provie live
> statistics AS YOU RUN (you have to wait till it's all done). i'm not
> looking for a leak. i'm looking for "whjat function call stakc
> allocated what memory - how much and when" as i can watch the
> profile over the runing time of the app and see as u interact with
> the app what happens and what allocates what and how much :)

Yeah, I've always been frustrated by that about dmalloc also.  That's
why I find valgrind so compelling.  I'm guessing memprof does similar
things without the VM overhead

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Have I told you today how much I love you?"  "Yes, but you may
  continue to repeat it for as long as you like."
  -- President Sheridan and Delenn, "Babylon Five"


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread Michael Jennings 
On Thursday, 03 November 2005, at 12:23:19 (+0900),
Carsten Haitzler wrote:

> first - check cvs. the coded hasnt been removed. it's
> there. lurking.

I know; the first thing I said was that it had not yet been
removed. :)

> the problem is - a lot of these moduels have problems - lots of
> them. the problems grow as basically the authors dont' maintain
> them. i have module changes in the pipeline that will mean yet more
> changes needed and given the history peolpe other than the authors
> will fix them to build - but they will still be badly done modules
> and grow worse as their code origins divert from main development

But there are, in my opinion, too few existing modules to be getting
this picky right now.  When we get to the point where we have all the
basics covered (load, bandwidth, memory, mail check, disk space,
analog and digital clocks), if we feel they need to be rewritten and
are willing to do so, great.  But something is better than nothing.

> (welcome to developemnt in cvs where apis are not fixed in
> stone!). the aim is to stop the tirade of "why doesnt this work"
> about these modules in cvs. the problem is that they need to be
> encouraged to be maintained per author separately from cvs.

Why?  Maintained, yes.  Per author, no.  Separately from CVS,
definitely not.  Having it public encourages others to pick up where
the original author left off.  CVS is first and foremost a
collaboration tool.  Removing code from CVS stifles collaboration and
contribution.

Imagine where kwo would be if e16 had been removed from CVS when e17
started.

> the code is there for posterity. this was discussed openly on
> #edevelop.

IRC is not the right venue for making decisions.  There were a
multitude of people, myself included, who were not involved in the
discussion because it was held at a time of day when we weren't
active.  The mailing list is better because it allows the discussion
to be carried on at differing times of day and allows more people to
be involved.

> as for the authors - the proff is that they dont get maintained -

What about the modules that are brand new, like rain?  How are you
concluding that they're unmaintained?  They haven't been in CVS long
enough to be unmaintained!

> i see no reason to ask nicely about code put in cvs then left up to
> others to fix - when they may or may not have time. all the "my
> monitor module reports 200% cpu" and not a single (correct) fix.

What about all the people like myself who use the monitor module all
day, every day, on multiple systems, and have no problems whatsoever?
Those who have problems with it don't have to use it; those who don't
shouldn't be penalized.

> anyway - the long term thing is that we cant go give a cvs account
> to every module writer who wants to make one to go put it in an ever
> expanding e_modules tree only to commit it then vanish and leave it
> up to others to maintain. they should maintain it themselevs on
> their own systems and upload tarballs to their own web pages if they
> want to release. get-e is providing a place for those without web
> space or without enough bandwidth.

SourceForge does that too.  If they want to maintain it independently,
there's nothing stopping them from doing so.  But keeping it in our
tree gives the rest of us the chance to step up if they disappear.

> this is a first step to DISCOURAGE use of the e_modules tree BEFORE
> its completely disabled for building and survives only as a dead
> code repository.

Not everyone agrees that that's the right approach.  That's why it
needs to be discussed.

> you are making a mountain out of a molehill here.

I don't see it that way.  I'm trying to keep the molehill from
becoming a mountain.

> no code has been deleted. it hasnt actually even been disabled.

I know.  And I want it to stay that way.  Others do too.

> this has split the modules into their own build trees and moved such
> development of "3rd party toys" out of cvs.

And what we're trying to say is that's not the right approach.  Maybe
they should go in proto/ instead, or whatever, but removing them from
CVS altogether isn't the answer.  All that does is stifle development
and code sharing.

> the moduels might be useful to many people - or fun, but where they
> are now, and how they build and are done, is not a good "example" to
> set.

The examples are the modules that come with E itself.  Most people
wouldn't see independent modules as examples when E comes pre-packaged
with some.  Especially if not all of them work.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Whoa.  Somebody computer programmers think is anti-social?  That
  I'd like to see."-- Sydney Penny, "Hyperion Bay"


---
SF.Net email is sponsored by:
Tame

Re: [E-devel] EWL themes

2005-11-02 Thread shadoi 

Brian Mattern wrote:

Really, it would be nice to create an e17/themes dir in the repo, so we'd have 
a central place for theme source. This would make it easier for people to go 
through and patch themes on theme API changes (when the original authors are 
too busy to do it themselves).




I was planning to write a more detailed report on the status of 
edevelop.org tomorrow, but  

I can provide a CVS (and/or SVN) repository on edevelop.org for themes, 
modules, and any other EFL apps that don't really belong in the main CVS 
tree.  This still allows them to retain some of the credibility of the 
project without cluttering things up.  On a related note, I've enabled 
the project module on edevelop.org, it's not perfect but it can provide 
a way for authors to track their projects and make releases (which can 
then be placed on get-e.org and perhaps eventually "blessed" and put on 
e.org.  The port of the e.org theme is almost complete for edevelop.org 
as well.


-Blake



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Tango!

2005-11-02 Thread Michael Jennings 
On Wednesday, 02 November 2005, at 21:35:22 (+0200),
Luchezar P. Petkov wrote:

> What is Tango?
> -- 
> Tango defines a standard icon style guidelines document that
> applications and desktop enviroments can adhere to. Work has started on
> creating a new base icon theme based on a standard icon naming
> specification. In addition, we provide transition utilities to create
> icon themes for existing GNOME and KDE desktops.
> http://www.tango-project.org

A standard naming convention is one thing.  Dictating appearance is
quite another.

> So, I know... the icon style doesn't fit well with the E17 default
> theme... but, I still think that the discussion is necessary, not only
> for "what will be the default icons in our WM?", it is necessary,
> becouse this project(Tango) is *very* important for every Open Source
> DE/WM out there.

I'm sure its developers think so, but it's going to take more than an
assertion to make it true for the rest of us.

Enlightenment is not in the business of looking and feeling like
anything else.  If we wanted to use Yet Another Windows Wannabe
desktop, we'd have plenty of alternatives to choose from.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Men are not subtle.  We are obvious.  Women know what men want.  Men
  know what men want.  What do we want?  We want women!  That's it.
  It's the only thing we know for sure." -- Jerry Seinfeld


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Re: [e-users] E laggy?

2005-11-02 Thread The Rasterman 
On Wed, 2 Nov 2005 23:59:01 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:

> On Tuesday, 01 November 2005, at 10:11:11 (+0900),
> Carsten Haitzler wrote:
> 
> > the former. as glibc changwed to dlopen()ing libraries on demand for
> > helper symbols to do this, and thus will remain so going forward
> > (ulrich dreppers words are "live with it!") i had to have my fixes
> > in memprof itself - and so they are. if i can get confirmations that
> > it works in other places too, maybe i will roll in some other
> > patches (debian moved libmemintercept to a subdir of lib - good
> > idea) and i might release a 0.6.0 of it or something.
> 
> Well, it had some issues building with an installroot, but it should
> be fixable.  I'll see what I can do.
> 
> Out of curiosity, what does memprof gain you that things like dmalloc
> and EFence don't?

efence is a memory overrun checker. dmalloc doesnt provie live statistics AS
YOU RUN (you have to wait till it's all done). i'm not looking for a leak. i'm
looking for "whjat function call stakc allocated what memory - how much and
when" as i can watch the profile over  the runing time of the app and see as u
interact with the app what happens and what allocates what and how much :)

> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
> n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
> ---
>  "You are waiting on a beach for a healing word to come.  Maybe an
>   apology in a bottle, maybe a flare that says, 'I'm sorry;' and the
>   hurting leaves you numb.  Will you forgive?  Will you forget?  Will
>   you live what you know?  He left his rights; will you leave yours?
>   You don't understand it.  Let it go."-- Newsboys
> 
> 
> ---
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> ___
> 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 (東京 日本)


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Re: [e-users] E laggy?

2005-11-02 Thread Michael Jennings 
On Tuesday, 01 November 2005, at 10:11:11 (+0900),
Carsten Haitzler wrote:

> the former. as glibc changwed to dlopen()ing libraries on demand for
> helper symbols to do this, and thus will remain so going forward
> (ulrich dreppers words are "live with it!") i had to have my fixes
> in memprof itself - and so they are. if i can get confirmations that
> it works in other places too, maybe i will roll in some other
> patches (debian moved libmemintercept to a subdir of lib - good
> idea) and i might release a 0.6.0 of it or something.

Well, it had some issues building with an installroot, but it should
be fixable.  I'll see what I can do.

Out of curiosity, what does memprof gain you that things like dmalloc
and EFence don't?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "You are waiting on a beach for a healing word to come.  Maybe an
  apology in a bottle, maybe a flare that says, 'I'm sorry;' and the
  hurting leaves you numb.  Will you forgive?  Will you forget?  Will
  you live what you know?  He left his rights; will you leave yours?
  You don't understand it.  Let it go."-- Newsboys


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] entrance x86_64 failed...

2005-11-02 Thread Michael Jennings 
On Saturday, 29 October 2005, at 12:47:46 (+0900),
Carsten Haitzler wrote:

> > If this file is normal and could theoretically appear regardless of
> > architecture, I should probably just put an rm -f in the spec file and
> > leave it at that.
> > 
> > Do you agree?
> 
> yeah - as it's harmless and a working file.

Done.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "There are times it seems to me I'm sharing you with memories.  I
  feel it in my heart, but I don't show it.  And then there's times
  when you look at me as though I'm all that you can see.  Those times
  I don't believe it's right; I know it."  -- O-Town, "All or Nothing"


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread The Rasterman 
On Wed, 2 Nov 2005 10:36:23 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:

> On Thursday, 03 November 2005, at 02:11:12 (+1300),
> Dale Anderson wrote:
> 
> > Just a quick note to advise the e_modules directory has been removed
> > from cvs.
> 
> It has not been removed, and it will not be unless and until such a
> decision is made after discussion on this mailing list amongst the
> developers.
> 
> > This was due to concern regarding the increasing number of modules
> > being commited, and the likely hood these would be left unmaintained
> 
> This is just silly.  Do you have any idea how many packages we have in
> CVS that haven't been touched in ages?  So what?
> 
> > These are now all updated and available from get-e.org (thanks devilhorns) .
> 
> They should not need to be downloaded from get-e.org or anywhere else.
> 
> > Module authors can now contact the get-e team for access to the site
> > to maintain their code and provide updates.
> 
> Ridiculous.  It should be up to the module authors whether or not they
> want to develop in our CVS tree or elsewhere, and whether or not they
> have abandoned their work or will continue maintaining it.
> 
> Not once did anyone ask the module authors on this list how they
> wanted to handle this situation.  This was a unilateral decision
> driven primarily by Hisham, though he apparently got raster's buy-in,
> and discussed only between the two of them while most of us were
> asleep.
> 
> Does anyone else see a problem here?  These kinds of decisions being
> made "behind closed doors" is not how an Open Source project should
> be.  Nor should people's work be removed from CVS without their input
> and consent.
> 
> This list is here for purposes of discussion.  So people need to stop
> acting like such significant decisions can and should be made on IRC
> and start COMMUNICATING.
> 
> To that end, I would suggest splitting up the individual modules so
> that each one builds and installs independently of the others.  It's
> not hard to do; I did it for tclock and calendar already.  So why not
> split the others up and let each module author control his own module
> rather than feeling like it's just part of a bigger pie?

first - check cvs. the coded hasnt been removed. it's there. lurking. the
problem is - a lot of these moduels have problems - lots of them. the problems
grow as basically the authors dont' maintain them. i have module changes in the
pipeline that will mean yet more changes needed and given the history peolpe
other than the authors will fix them to build - but they will still be badly
done modules and grow worse as their code origins divert from main development
(welcome to developemnt in cvs where apis are not fixed in stone!). the aim is
to stop the tirade of "why doesnt this work" about these modules in cvs. the
problem is that they need to be encouraged to be maintained per author
separately from cvs.the code is there for posterity. this was discussed openly
on #edevelop. as for the authors - the proff is that they dont get maintained -
i see no reason to ask nicely about code put in cvs then left up to others to
fix - when they may or may not have time. all the "my monitor module reports
200% cpu" and not a single (correct) fix.

anyway - the long term thing is that we cant go give a cvs account to every
module writer who wants to make one to go put it in an ever expanding e_modules
tree only to commit it then vanish and leave it up to others to maintain. they
should maintain it themselevs on their own systems and upload tarballs to their
own web pages if they want to release. get-e is providing a place for those
without web space or without enough bandwidth.

this is a first step to DISCOURAGE use of the e_modules tree BEFORE its
completely disabled for building and survives only as a dead code repository.

you are making a mountain out of a molehill here. no code has been deleted. it
hasnt actually even been disabled. this has split the modules into their own
build trees and moved such development of "3rd party toys" out of cvs. the
moduels might be useful to many people - or fun, but where they are now, and
how they build and are done, is not a good "example" to set.

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


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread The Rasterman 
On Wed, 02 Nov 2005 10:46:03 -0500 dan sinclair <[EMAIL PROTECTED]> babbled:

> > Please also note that modules_extra has been removed from the default E 
> > module search path and modules need to be installed to ,
> > 
> > $PREFIX/lib/enlightenment/modules or,
> > ~/.e/e/modules
> > 
> 
> Whats the point of removing this from the search path? It causes no
> issues and allows people to keep their official and unofficial modules
> in separate directories. And yes, .e/e/modules is there, but what if I
> have two users? They both have to have a copy, which sucks.

frankly - it was ADDED as a hack. the original intent was to have a system
moduels dir by default and that's it. e shouldnt go looking in dirs not
provided by IT by default. a user CAN add a new module dir to the search path -
but e shouldnt be poking around in these dirs if they may or may not exist.

as for modules in modules_extra - it's just an unclean hack imho. i always have
said that and have relented due mostly to laziness.

> I'd say, this directory should stay as it really dosen't cause any
> issues.

it WILL cause issues soon enough - when we add a module manager code that has
to hunt the fs for modules able to be loaded. adding more and more extra module
dirs (1 isnt too bad - but where do u stop?) just means more magic divination
by such a codebase. if 3rd party moduels get installed int he same tree(s)
(there are only 2 ~/.e/e/modules and PREFIX/lib/enlightenment/modules) then its
much easier to deal with from a user POV (no need to add another dir) and a
code POV.

> dan
> 
> 
> 
> 
> ---
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> ___
> 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 (東京 日本)


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] video corruption with xcompmgr

2005-11-02 Thread The Rasterman 
On Wed, 02 Nov 2005 09:46:55 -0500 Mike Russo <[EMAIL PROTECTED]> babbled:

> Generally e17 works well with a compositing manager running, however I 
> will occasionally experience video corruption issues of the sort shown 
> in the screenshot. They'll commonly happen when dragging a window 
> between my two screens (running as one using nvidia twinview w/ xinerama 
> enabled), and always either at the top or bottom of the screens. killing 
> xcompmgr will make the corruption disappear, and generally just moving a 
> window over the areas will force them to redraw correctly. any ideas?

issues related to xcomposite/xrender. not e. i can guarantee that.

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


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Tango!

2005-11-02 Thread Nathan Ingersoll 
On 11/2/05, Morten Nilsen <[EMAIL PROTECTED]> wrote:
Unless I totally misread the project website, the point of tango isn'tthe actual set of icons presented on the site, but the filenames of saidicons
I believe it's a combination of things including the naming
conventions, a base set of icons, and a set of style guidelines for
developing further icons.

Re: [E-devel] Tango!

2005-11-02 Thread Morten Nilsen 

Hisham Mardam Bey wrote:

On 11/2/05, Luchezar P. Petkov <[EMAIL PROTECTED]> wrote:



So, I know... the icon style doesn't fit well with the E17 default
theme... but, I still think that the discussion is necessary, not only
for "what will be the default icons in our WM?", it is necessary,
becouse this project(Tango) is *very* important for every Open Source
DE/WM out there.



I personally think that just adding Tango for the sake of having the
icon set there isnt the way to go. E17's default theme tried to
maintain a consistent look across E, Ewl, Etk etc. so we need to
repect that and have icons that go along with this look and feel.

This is not to say that we cant create a theme that uses those icons
and make it available for everyone to use.


Unless I totally misread the project website, the point of tango isn't 
the actual set of icons presented on the site, but the filenames of said 
icons


--
Morten


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Tango!

2005-11-02 Thread Hisham Mardam Bey 
On 11/2/05, Luchezar P. Petkov <[EMAIL PROTECTED]> wrote:

> So, I know... the icon style doesn't fit well with the E17 default
> theme... but, I still think that the discussion is necessary, not only
> for "what will be the default icons in our WM?", it is necessary,
> becouse this project(Tango) is *very* important for every Open Source
> DE/WM out there.

I personally think that just adding Tango for the sake of having the
icon set there isnt the way to go. E17's default theme tried to
maintain a consistent look across E, Ewl, Etk etc. so we need to
repect that and have icons that go along with this look and feel.

This is not to say that we cant create a theme that uses those icons
and make it available for everyone to use.

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


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Tango!

2005-11-02 Thread Luchezar P. Petkov 
Hi, list.
I think we(you?) need to discuss the future of the E17 icon set.
So, my suggestion is to use the Tango icon theme.
---
What is Tango?
--
Tango defines a standard icon style guidelines document that
applications and desktop enviroments can adhere to. Work has started on
creating a new base icon theme based on a standard icon naming
specification. In addition, we provide transition utilities to create
icon themes for existing GNOME and KDE desktops.
http://www.tango-project.org
--
So, I know... the icon style doesn't fit well with the E17 default
theme... but, I still think that the discussion is necessary, not only
for "what will be the default icons in our WM?", it is necessary,
becouse this project(Tango) is *very* important for every Open Source
DE/WM out there.

Thanks.
Luchezar "ManowarrioR" Petkov




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EWL themes

2005-11-02 Thread dan sinclair 
> What's the point of option 1?
> 
> Doesn't matter whether they are unmaintained in 'ewl_themes' or in
> 'ewl'.
> You can remove the offending directories from the SUBDIR variables in
> Makefile.am, so they won't be distributed etc.
> If anyone succeeds in fixing them, you can put them in again.

Well, because I never though of that, heh. It's always the obvious
solutions. 

The one change I think we should make in that case is move default to
winter, to stop what could be a confusing situation, heh.

dan



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EWL themes

2005-11-02 Thread Brian Mattern 
Hey,
I've been meaning to get back to the winter ewl theme (and some ewl-e17 theme 
touchups), but keep getting distracted by other things :) In the mean time, I 
would agree with splitting them out.

Really, it would be nice to create an e17/themes dir in the repo, so we'd have 
a central place for theme source. This would make it easier for people to go 
through and patch themes on theme API changes (when the original authors are 
too busy to do it themselves).

As for organization, i can think of two ways of doing it -- by theme and by 
app. e.g.:

e17/themes/
winter/
e17
ewl
elicit
e17/
e17
ewl
elicit


OR

e17/themes/
e17/
e17
winter
...
ewl/
e17
winter
...
elicit/
e17
winter
...

Ideally, it would be nice to have both (does cvs play well with symlinks?)
i.e. set up things by theme, and them link them in by app (maybe under 
e17/themes/applications/...) That way it would be as easy to get 'all winter 
themes' as it would be to get 'all e17 themes'.

--
rephorm

On Wednesday 02 November 2005 11:01, Nathan Ingersoll wrote:
> I'd like input from HandyAndE and rephorm in particular on this one as they
> are original authors on two of them.
>
> On 11/2/05, dan sinclair <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > Nathan and I have been looking at the themes for EWL and have realized
> > that zero, default and skeleton are woefully unmaintained (partially our
> > fault as we never update them).
> >
> > So, we're currently thinking to split those themes out of the default
> > EWL CVS and just provide the E17 theme. Which we keep updated as much as
> > possible as it's the default theme now.
> >
> > We could either do a separate CVS directory, or move them to
> > edevelop.org  and depend on the ability for .edj's
> > to be de-compiled to
> > let people get the source code.
> >
> > What does everyone think? Leave em where they are and let them rot, move
> > to an EWL-themes directory in CVS somewhere or rip em out to edevelop?
> >
> > dan
> >
> >
> >
> > ---
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server.
> > Download
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EWL themes

2005-11-02 Thread Tilman Sauerbeck 
dan sinclair <[EMAIL PROTECTED]> [2005-11-02 11:25]:
> We could either do a separate CVS directory, or move them to
> edevelop.org and depend on the ability for .edj's to be de-compiled to
> let people get the source code.

What's the point of option 1?

Doesn't matter whether they are unmaintained in 'ewl_themes' or in
'ewl'.
You can remove the offending directories from the SUBDIR variables in
Makefile.am, so they won't be distributed etc.
If anyone succeeds in fixing them, you can put them in again.

Keeping them in CVS is a good idea though... Revision history is
important :)

Regards,
Tilman


pgpbkguGQ7Jra.pgp
Description: PGP signature

Re: [E-devel] EWL themes

2005-11-02 Thread Nathan Ingersoll 
I'd like input from HandyAndE and rephorm in particular on this one as they are original authors on two of them.On 11/2/05, dan sinclair <
[EMAIL PROTECTED]> wrote:Hello,Nathan and I have been looking at the themes for EWL and have realized
that zero, default and skeleton are woefully unmaintained (partially ourfault as we never update them).So, we're currently thinking to split those themes out of the defaultEWL CVS and just provide the E17 theme. Which we keep updated as much as
possible as it's the default theme now.We could either do a separate CVS directory, or move them toedevelop.org and depend on the ability for .edj's to be de-compiled to
let people get the source code.What does everyone think? Leave em where they are and let them rot, moveto an EWL-themes directory in CVS somewhere or rip em out to edevelop?dan---
SF.Net email is sponsored by:Tame your development challenges with Apache's Geronimo App Server. Downloadit for free - -and be entered to win a 42" plasma tv or your very ownSony(tm)PSP.  Click here to play: 
http://sourceforge.net/geronimo.php___enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread Nathan Ingersoll 
On 11/2/05, Michael Jennings <[EMAIL PROTECTED]> wrote:

Ridiculous.  It should be up to the module authors whether or not theywant to develop in our CVS tree or elsewhere, and whether or not theyhave abandoned their work or will continue maintaining it.


I have to agree with mej on this. I understand the desire to keep
unmaintained code out of the main tree, but I don't think forcing the
decision on module authors is the way to go. It also makes
collaborative development difficult unless they setup their own CVS
repository, and that seems a little ridiculous for a single module. It
also seems a bit pre-mature to call these modules unmaintained. They
have been updated as API's have changed and while there have not been
significant feature changes recently, there is nothing preventing them
from being expanded as more widgets features become available in the
core. For example, the weather module is probably feature complete
until the config dialog/widgets settle out.

If we really don't want these modules in the main e17/apps directory,
why not move them to proto until they are either accepted into the main
e17 modules or deprecated? We've already declared proto as a test
playground, so I don't see a reason that people we've already given CVS
access to couldn't put their modules in that area for development.

We're really talking about two issues, development and distribution. I
can't see anyone having a complaint about putting the modules up for
distribution on get-e.org, but by officially excluding all extra
modules from CVS, they would get far less developer exposure. I know
I'm far more likely to fix a problem in a module in CVS than one I can
only get a tarball for from get-e.org. I'd imagine some of the
packagers would have little motivation to work on them as well.
Not once did anyone ask the module authors on this list how theywanted to handle this situation.  This was a unilateral decision
driven primarily by Hisham, though he apparently got raster's buy-in,and discussed only between the two of them while most of us wereasleep.
There was some discussion in #edevelop that I saw, but it was brief and
I was given the impression that it would be left up to module authors.
Does anyone else see a problem here?  These kinds of decisions being
made "behind closed doors" is not how an Open Source project shouldbe.  Nor should people's work be removed from CVS without their inputand consent.
The consent issue is actually a pretty large one. We've never removed
peoples work from CVS without their permission, just take a look at the
AUTHORS files in misc. How long has it been since most of them have
been seen? Some of them are kept in memory of their authors.

So why don't we move the modules to proto, and then use get-e.org as a distribution mechanism?

Nathan

[E-devel] EWL themes

2005-11-02 Thread dan sinclair 
Hello,

Nathan and I have been looking at the themes for EWL and have realized
that zero, default and skeleton are woefully unmaintained (partially our
fault as we never update them).

So, we're currently thinking to split those themes out of the default
EWL CVS and just provide the E17 theme. Which we keep updated as much as
possible as it's the default theme now.

We could either do a separate CVS directory, or move them to
edevelop.org and depend on the ability for .edj's to be de-compiled to
let people get the source code.

What does everyone think? Leave em where they are and let them rot, move
to an EWL-themes directory in CVS somewhere or rip em out to edevelop?

dan



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread dan sinclair 
> Please also note that modules_extra has been removed from the default E 
> module search path and modules need to be installed to ,
> 
> $PREFIX/lib/enlightenment/modules or,
> ~/.e/e/modules
> 

Whats the point of removing this from the search path? It causes no
issues and allows people to keep their official and unofficial modules
in separate directories. And yes, .e/e/modules is there, but what if I
have two users? They both have to have a copy, which sucks.

I'd say, this directory should stay as it really dosen't cause any
issues.

dan




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread Michael Jennings 
On Thursday, 03 November 2005, at 02:11:12 (+1300),
Dale Anderson wrote:

> Just a quick note to advise the e_modules directory has been removed
> from cvs.

It has not been removed, and it will not be unless and until such a
decision is made after discussion on this mailing list amongst the
developers.

> This was due to concern regarding the increasing number of modules
> being commited, and the likely hood these would be left unmaintained

This is just silly.  Do you have any idea how many packages we have in
CVS that haven't been touched in ages?  So what?

> These are now all updated and available from get-e.org (thanks devilhorns) .

They should not need to be downloaded from get-e.org or anywhere else.

> Module authors can now contact the get-e team for access to the site
> to maintain their code and provide updates.

Ridiculous.  It should be up to the module authors whether or not they
want to develop in our CVS tree or elsewhere, and whether or not they
have abandoned their work or will continue maintaining it.

Not once did anyone ask the module authors on this list how they
wanted to handle this situation.  This was a unilateral decision
driven primarily by Hisham, though he apparently got raster's buy-in,
and discussed only between the two of them while most of us were
asleep.

Does anyone else see a problem here?  These kinds of decisions being
made "behind closed doors" is not how an Open Source project should
be.  Nor should people's work be removed from CVS without their input
and consent.

This list is here for purposes of discussion.  So people need to stop
acting like such significant decisions can and should be made on IRC
and start COMMUNICATING.

To that end, I would suggest splitting up the individual modules so
that each one builds and installs independently of the others.  It's
not hard to do; I did it for tclock and calendar already.  So why not
split the others up and let each module author control his own module
rather than feeling like it's just part of a bigger pie?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Act like you expect to get into the end zone."-- Joe Paterno


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [ANNOUNCE] e_modules removal from cvs

2005-11-02 Thread Dale Anderson 

Hi All

Just a quick note to advise the e_modules directory has been removed 
from cvs.


This was due to concern regarding the increasing number of modules being 
commited, and the likely hood these would be left unmaintained .


These are now all updated and available from get-e.org (thanks devilhorns) .

Module authors can now contact the get-e team for access to the site to 
maintain their code and provide updates.


Please also note that modules_extra has been removed from the default E 
module search path and modules need to be installed to ,


$PREFIX/lib/enlightenment/modules or,
~/.e/e/modules

Regards
Dale (swishy) Anderson.



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel