RE: balsa...



Ok, here's what needs to be done.  Someone needs to find out if Stuart Parmenter
is wanting to keep the URL "www.balsa.net" or if he wants to give that to someone
else.  Then we need someone to act as our "window to the world" so to speak, and 
actually manage the site.  :-)  That someone had better not be me, cause I really
don't want to do web work, but will if nooone else volunteers. 

We need to start working on a plugin API for the current configuration.  What
I would like to see is something based on the existing GTK concept of signals and
callbacks.  These plugins should also be able to easily extend the current preferences
system so that they can be disabled/enabled/adjusted without it "feeling" like a plugin.

For example, a "trashcan" plugin could register itself as wishing to receive delete events
and then copy the message to some defined folder before the deletion took place.  In this
way plugins could serve as a rather heavyweight form of "filter".  Of course, this is merely
an example, as Trashcan functionality probably would make more sense as a core feature.  The
plugin API should be powerful enough to make things such as this possible, though.  If someone
could come up with a good implementation method for this, please propose it to the list.  It
seems that GTK+ provides a lot of helper functions that would be useful here, but I haven't 
investigated yet.  This shouldn't be too hard, though.

We need to get some sort of support for address books.  Sometime later tonight, I
will commit a fix to CVS to support Drag'n'Drop from Gnome-Card.  If possible, I'll also connect
the little addressbook buttons so that they call gnome-card.  This isn't the prettiest or best thing,
it is still the right thing to do for now.  :-)  Actually, if Gnome-card ever gets to the point
of supporting some sort of "Grouping", it might even be the best way to do this.

We need to work on IMAP folders.  Currently subscribing to IMAP folders is a real pain.  Being
able to do simple things like "List all subscribed folders" should be easy.  In balsa it is not.  I'll
take a look at this later tonight as well.  Also, creating new folders on the server should be possible.
Hopefully, I can have these two things fixed in a couple of days, but no promises.:)  I'm still not
certain how much libmutt provides, but it looked like these kinds of basics would be possible, if
a little obtuse.

Also, we need to address several pesky user interface and transfer protocol interations that just
aren't right.  The folder system that balsa currently uses allows multiple mailboxes to be opened at
once.  With local mailboxes, this is great.  With IMAP folders this tends to be a sure way to cause
a crash.  This doesn't look impossible, or even terribly difficult to fix, but someone has to do it.
I'll look at it as soon as possible, but if someone else wants to chime in with a patch, they are welcome
to do so.  It really shouldn't take more that a couple of lines, but exactly where and how to implement
it without breaking things could be a small challenge.

Also, at some point we need progress bars on the POP folder, and non-blocking IO and other such niceties.
I personally do not believe that these should be priorities for the Balsa project at this instant, as there
are efforts underway to develop VERY nice CORBA components for Gnome-libs that should be more than adequate.
Until there are at least a few things coming in this direction, any significant effort to fix libbalsa will
probably just produce duplicated work.

All of those things are critical, MUST do features.  Beyond that it would be able to read HTML mail using
gtk-xmhtml.  If someone has any bright ideas how a gtk-xmhtml widget can be mapped onto a Gnome-canvas,
I would love to hear them.  :-)  That would be the easy way out, anyway.  Failing that we could consider
replacing the whole Balsa-Message with a system based around gtk-xmhtml.  Something that sort of converted
even text messages to HTML-"lite" and therefore would have all of the advantages of the current system
(i.e. automatic viewing of picture attachments, etc.).  This is feasible, but difficult.  If noone else
jumps up and gets excited about working on this, I'll start looking into it (I already have a little).

Someone else mentioned calendaring earlier.  WOW, someone here finally mentioned calendaring w/r/t a UNIX
email app!  :-)  Seriously, this is something that Unix Mail Clients desparately need.  Once we have
a nice CORBA calendaring server, support for this should be possible.  Some corba wizards really need
to get to work on the idea of a "central calendar server" for Gnome.  I've heard little snippets of
talk about this, but not enough to have a clue when it will be done.  But this is definately a priority
thing for me as soon as it is possible to do it the right way.  I know several people/organizations that
would want this.

Finally, is personality support.  I will post more on this later, but I think that basically the idea
is that the user should be able to easily send a message using "from" addresses other than the default.
It should also be possible to configure this on a per mailbox basis.  It really looks like this should
not be difficult with 

Ok, that's quite a list.  :-)  My suggestion is that if you want to get to working on things for Balsa,
just find something that you need, and get to work on it.  If you don't have CVS access, just send
a unified diff (i.e. output of cvs diff -u filename) to me and I'll put it up there.  Well, after
checking to make sure that it compiles, etc.:-)  Make sure that you give me a short description of the
change for the ChangeLog, of course.  :)

Basically, if you want it done, Just Do It.  If you don't think you did it just right, post it to the list,
or mail it to me.  We can always work on it some before putting it into wide distribution. :)

Ok, I'm going to post a summarized version of this list to "http://www3.pair.com/jsight/balsawork/" later
tonight as kind of a work-in-progress chart.

Finally, I am fully aware of the "crash on reply to mime multipart mesage" but as well as the lack of
keyboard navigation when reading messages.  The crash bug fix is committed now, and the keyboard nav.
fix soon will be (just need to do some cleanup to use GDK's defines appropriately and name the functions
more reasonably).  These alone make Balsa much more fun to use, IMO.  :-)

Enjoy.

On Wed, 07 Apr 1999 19:10:19 Dan Cohn/INS wrote:
> 
> 
> It sounds to me like what we really need now is a resource manager to
> control the codebase and distribute tasks. Once we reach that point, we
> can work to identify tasks, make sure they are properly delegated, make
> sure the committed code is clean, and handle releases. 
> 
> We should find this person and come to consensus as that person as the
> project lead. 
> 
> I understand that there are a number of features people would like to see,
> and those ideas are great, but what we have now is a product that barely
> does most of the core functions it was intended to do. I believe we should
> concentrate for a moment on organization, then code organization, then
> basic functionality, and then on advanced features.
> 
> I suggest we find a volunteer from amongst us with a good deal of dev and
> project (esp gpl project) management experience who can serve as a
> clearing point for the work that needs to be done, atleast until we are
> well enough organized that we have a clear concept of tasks, priorities,
> and code organization to get from here to there.
> 
> thoughts?
> 
> dc
> 
> 
> -- 
> 	FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail balsa-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.

---------------
Jesse D. Sightler
http://www3.pair.com/jsight/

"An honest answer can get you into a lot of trouble." 
         - Anonymous



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]