Re: Several balsa bugs I'm about to submit to bugzilla.

[Carlos Morgado <chbm gnome org>]

On Mon, 01 Dec 2003 23:17:52, Miquel van Smoorenburg wrote:
> On Mon, 01 Dec 2003 18:52:09, Carlos Morgado wrote:
>

> >
> > This is a good observation however in IMAP doing what balsa does and what
> you
> > are proposing is the same thing. Also, some imap servers are better than
> > others at this.
> 
> But it appears that balsa also gets the number of read/unread messages in
> the folder, which means the IMAP server has to scan the whole folder.

Oh, right. Well, that happens cause we don't know if the user is switching or  
just looking at all mailboxes.
Maybe a separate tree view is needed to subscribe.
(btw, I just created a new subfolder and it was subscribed right away.  
however, this might be server dependent - yes that sounds like a lame excuse  
but it means iirc there is at least one server where we need to bend over  
backwards to create a folder and subs it right away)

> 
> > > folder-menu
> > >
> > >
> > > The options you get in the folder window when right clicking
> > > are confusing and should be more context-dependent. Right now,
> > > for example when selecting "new IMAP subfolder" it doesn't
> > > even remember where in the tree you clicked on it and you have
> > > to enter manually "create as subfolder of". And you can click
> >
> > That is anoying yeah.
> >
> > > on a local folder and get "new remote IMAP mailbox".
> > >
> >
> > You start with local folders only - how do you add an IMAP mailbox ?
> 
> So the folder tree should have a root on which you can right click
> to add mailboxes / folders.
>

oh. "duh" :)

> 
> > > would be more logical and it would allow one to keep multiple
> > > folder collections. You would also be able to set the folder type
> > > for that tree (i.e. mbox, maildir, MH).
> > >
> >
> > you can't just set the folder type! that means recreating the folder from
> 
> > scratch!
> 
> I mean when adding it. Say "add local mailbox" or "add local mailbox  
> folder"
> where you can select the type (mbox, mh, whatever).
>

so it's just rearranging the existing new mailbox options ?


> 
> > "Mark as special mailbox" belongs in the mailbox menu.
> 
> Why, there are only 4 of those and if you have 100 folders why should every
> menu have those 4 options in it ? It's dangerous too, it's way too easy to
> accidentally mark a folder as Trash for example (then empty Trash .. argh).
>

Easy answer is seting the speacial mailboxes needs a mailbox tree.
That issue of marking a mailbox as special by mistake can be solved by making  
that option a 2 level menu.

> > > The "File -> New" hierarchy should look like this:
> > >
> > > - Local mbox folder set
> >
> > this doesn't make sense, a "mbox folder set" is just a directory with
> mboxes.
> 
> Exactly. This is to get consistent naming.
>

But new local mbox isn't meant to create a bunch of mboxes, just one,  
somewhere. I still don't get it.

> > > - Local MH folder set
> >
> > Some MUAs can't see nested MH folders
> 
> But we're using balsa which can.
>

But sometimes we login via ssh and use other stuff ;)


> >
> > Are you trying to group local folders by type ? I don't get it.
> 
> I'm just proposing to do this the way almost every other MUA does it,
> like evolution, mozilla, outlook.
>

Ah. Well, evo makes the local folders (despite their type) look like an imap  
server to make everything pretier but it doesn't serve any real functional  
reason. You don't even get a unified tree. It looks like
- Local Folders
 + Inbox
 + Drafts
 + Foo
 + MHFolder
   + AnotherMHFolder
 + MaildirFolder
- user@imapserver
 + Inbox
 + xpto
- user@anotherserver
 + Inbox
 + frobate
+ Other Stuff
+ More Other Stuff

In balsa you get the local folders in the top level

> > I think have a hierarchy for local folders makes stuff harder to find.  
> I'm
> a
> > great fan of alphabetical order.
> 
> Okay so there should be a common folder root under which you can add
> a local or remote mailbox, or a local or remote folder where folder
> means directory instead of mailbox.
>

Hum, I'd rather have balsa mkdir -p and let you type newdir/mbox1 and create  
newdir if needed. Having empty dirs and mailboxes that look just like empty  
dirs is confusing (for balsa :))

> > > folder-prefs
> > >
> > > The folder preferences menu should have some extra options:
> > >
> > > - Standard Cc: / Bcc: / Reply-To: header settings
> >
> > this is all part of identities
> 
> Okay, true. But folder-specific settings should override the
> identity settings, because I have groups of folders that use
> the same identity yet need slightly different customized headers.
>

Storing the same thing in 2 diferent places gets messy in my opinion. If you  
need that you should just create diferent identities. Having said that, the  
composer window probably need a "you're using identity X" somewhere.

> Oh and ofcourse the default To: should be settable for mailinglists.
> That's something that doesn't really belong under an identity
> (unless you want to have 1 identity per list).
>

This was discussed before. The general consensus is we should believe the  
Reply-To headers.

> > > - Possibility to add customized headers (X-whatever: yes)
> >
> > this might be usefull for RIPE mail :)
> 
> Exactly. Not only that, I want to add an "X-Sent-Folder" header to every
> outgoing message. Together with an automatic Bcc: to myself, I can then
> filter mail to the Sent mailbox on the server. Why you ask? Well because

Hum. This makes sense.

> otherwise all mail I send is transfered to the remote server twice:
> once as outgoing SMTP, and another time when saving that mail to the
> Sent mailbox on the IMAP server (IMAP should /really/ have included
> a way to send messages /and/ save them in a Sent box!).
>

It does. Some servers will send anything you drop in a special folder (like  
balsa's Outbox). Others don't.

> > > - (perhaps) Location of drafts / sent folder
> > >
> >
> > Ok, Sent could be a Identities thing
> 
> Both. I like to have my sent messages in the same folder as the
> message itself, so the whole discussion can be read back.
>

This makes sense, however i don't think it will make its way to 2.0.


> 
> > > external-editor
> > >
> > > It would be great if Balsa could run an external editor in the
> > > standard compose window.
> > >
> >
> > eeek!
> 
> Again evolution inspired. Check the "gnome-vim" project.. *awesome*
>

evo is one big bonobo cluster so you can easily embed the bonobo vi control  
(*gasp*) instead of the evo editor bonobo control. in fact, I think that's  
why the vi control was writen :)
balsa however basicly doesn't know about bonobo so there would be a lot of  
work involved just for a visual thingy ;)


-- 
Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/ 
0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A