On 11/1/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Oct 2007 20:09:17 -0400 "Hisham Mardam Bey"
> <[EMAIL PROTECTED]> babbled:
>
> > Hello gang,
> >
> > I'm sure some of you have (passively) read some of the discussions
> > that are occurring on #edevelop from time to time regarding the
> > direction this project is taking. I am mainly talking about E17, the
> > window manager, and not the entire EFL.
> >
> > The main discussion was centered about how we're developing E17 and
> > where its going. We now have two places where we keep TODO items and
> > bugs, the TODO file in apps/e, and bugzilla. The way things are going,
> > we have several "open" features in E17 that are partially done, some
> > major, some minor. Among those features are EFM, and the First Time
> > Run Wizard (FTRW).
>
> i think i did warn people that if this is moved to bugzilla i am certain i 
> will
> probably not read it - having a web browser up consuming half my screen and a
> web interface to trawl through painfully just to check what people have filed 
> is
> a sure way to make me avoid it. bugzilla is painful. compared to the compact
> simplicity of a TODO file in CVS - it's an abomination (from a developers 
> point
> of view). a lot of you may just love the web, and web ui's, and sit and drool
> over your gmail web page etc. etc. - but i do not. i find it royally painful.
> so as i said - the result is me not reading the bug reports/feature requests.
>
> > EFM was supposed to be a simple file selector, it then grew into a
>
> actually no - it was meant to be BOTH a file selector back-end AND a simple
> filemanager. there is no point making 2 of them separate. they do the same
> thing. list files.

Granted, but if the file manager functionality is going to take a lot
of time to complete we should just put it on hold and work on the bugs
in the TODO.

> > file manager, it then started getting custom directory and window
> > configuration abilities, and then grew so big it needed its own
>
> config has been there from day 0 so it can look like a list (used int he file
> selector) or icons (desktop bg/fwin views). config is there as simple twiddle
> knobs for icon size and more.
>
> > process. As it stands, none of its features are 100% complete and
>
> no - the process was there to split file IO out ot a slave so the WM doesn't
> hang doing file IO to slow file systems (eg AFS, a CF/SD card plugged in via a
> USB 1 card reader etc.). i actually did this because of slowness in the file
> selector - not the file manager. it has a bonus of making the file manager
> better too.
>
> > almost without bugs, except the file selector. The file selector is a
> > core part of E17 (for obvious reasons), but the file manager is really
> > not. I would classify it as a nice to have feature, along with desktop
> > icons, but its nothing major that can prevent a release from
> > happening.
>
> there's a bunch of things to finish off with the fm - but it's not a huge
> amount of work to finish ti to simple usability. it's almost there. just the
> actual file operations need fixing to work properly in all cases and report
> errors properly. that's about all that's really left to do here (other than
> initial setup of Desktop so u have some links to places like your homedir). i
> wanted to add links to the ~/.e/e/themes, backgrounds etc. dirs for trivial 
> DND
> of downloaded items etc. the FM allows that and it's ALMOST there.
>
> > The FTRW is a useful feature to have that has also been started and
>
> the wizard core is pretty much done - i paused to go fix the default theme ans
> i frankly was disgusted with the look of the wizard and couldn't continue 
> until
> i fixed things. i wanted to get that settled and come back. i want to get the
> first few pages done that demonstrate how to do most things - then the rest 
> can
> be filled in as needed. what pages are to be done is listed in the wizard - 
> but
> we can make it more minimal to save time.
>
> > has not seen completion yet. It was always on the TODO, but it sprung
> > out of no where at a certain point in time during the EFM development
> > cycle. Although its a nice and very useful feature, and I think it
> > would be a good idea to have it available when we have a release, its
> > taken development time from EFM and other incomplete features in E,
> > and is currently not finished. Yet another incomplete and relatively
> > big feature.
>
> it is really just these 2 big ones with smaller cleanups that need doing - tho
> default theme cleanup is not a small task BTW - i'm commenting the .edc 
> heavily.
>

I'm not criticizing how these things are designed or saying they are
"bad" or extra features. I am just saying that as it stands, they need
a good amount of work and have the tendency to grow. We should say
that we want to make them do a, b, and c, and freeze anything else.

> > Some other items in the TODO are considered medium sized tasks, and
> > the majority can be considered small tasks. I don't know about the
> > state of things in bugzilla, but we can assume the same as with the
> > TODO.
>
> lots of small tasks too - that will sink a lot of time. a lot of these can 
> just
> be done in parallel anyway.
>
> > So the main question I have for everyone is, what now? We're writing
> > code, time is passing, and we're not closing (or barely closing) any
> > of the items on the TODO. New features that are not always planned
> > make their way every now and then, and we're never substantially
> > closer to a release or a release candidate. What do you folks propose
> > we do to handle this problem? Should we freeze the addition of new
> > items to E17 (similar to the freeze done a while back) and concentrate
> > on closing all the TODO items and the bugs? Whatever decision we make,
> > we need to do something about the way E17 is being developed, and the
> > pace at which it is being developed at.
>
> the problem is the pace. there are lots of TODO items - most not being done. 
> in
> doing efm and wizard - i am trying to knock of some of the big fat items and
> get them started/going/ to a state of relative health. i agree we need to
> knuckle down on those. the wizard core *i think) is done. its' a matter of
> pages to do the setup. we can make it simple - but we do need it. we have
> enough problems with users asking about empty/blank app menus and other things
> that we need to fix in code on setup (i.e. - find all the xdg menus and ask
> user which one they want etc.).

So I guess the next move is to *try* and organize this mess and come
up with a rough schedule for things. I know we dont usually do this
kind of thing, but I firmly believe that if we dont set a schedule,
nothing is ever going to be done anytime soon.

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to