[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KDE task orientation -> Konqueror-KMail integration / Folder
From:       Sebastien Laout <sebastien.laout () tuxfamily ! org>
Date:       2003-10-24 18:22:39
[Download RAW message or body]

> A usual project has several e-mails and other documents [...]
> I cannot pass any command line arguments to kmail to open it as
> e-mail (it just gets set as e-mail body text as a whole, including
> all the headers).
I'm the developer of BasKet and this program could interest you for
group all items of a current task (files, mails, contacts...) in one
place.
A user has mailed me and said me that he was using my app for this
purpose (future versions will allow this usage easier).
I doesn't want to make advertising here, so please mail to know BasKet
adress (if you want to test it) : not the way you've descibed but it's
working.

> KMail is and will always be an email client, no more, no less. But at 
> some point it might be possible to directly show email messages in 
> Konqueror or a not yet existant Task Manager.
Hum... Yes, have mail storage in a filesystem format is not the
main goal of a mail client but it's a KDE Integration work (and KMaim is
a KDE program ! ).

I was also wanting this "feature" and KMail already have a ~/Mail folder :
it's intrusive at all !!
- Because it's a sort of config folder and this must be a hidden folder
(~/.kmail in the UNIX convention) !
- It is shown at the user : clutter the (already cluttered (by other apps) )
folder and can disturb the user : if this folder is shown, it have a
interest : users (as me) will open it and look at, play with files... I'm
not sure that KMail will agreee if users play with (quite sort of config-)
files !

The new solution proposed here is good IMHO : we can add/remove mails with
removing a file, create folders... by creating folders (!)...
The KMail tree is... a tree (arborescence) ! Filesystem is also a tree.
I do not view problems.
Of course, whereas each ~/Mail folders will represent a KMail folder and
each ~/Mail/* files will represent mails (and can be previewed in Konqueror,
as a simple HTML and opened with KMail), config files (view config, read
mails...) must be hidden in the folders : Users will just see mails in
Konqueror and can add folders (if KMail see a new folder without attached
config hidden file, it create it on the fly, of course).

Do not forget (the ultimate argument ;-) ) : UNIX is a filesystem based OS :
We see periphs as files, we see process as files, we see pipes as files...
See mails as files is just a small formality and is important for consitancy !

In hope I've convinced KMail team (yes it isn't the right mailing) that some
users (at least Me, Mark...) want have a UNIX mail conception (think to those
who edit mails in konsole : filesystem paradigm is good).

My app (BasKet) will also, in the future, allow to have baskets and items in
physical folders and files : I considere this as a good feature and not as
a gadget.
For example, users will can use the standard KDE/GNOME/whateverElse file save
dialog to save files as items.
Can also be realised in KMail : save file in "Send box" will allow KMail to
directly send it :
- Create a file with an app
- Save it into KMail "To send" folder
- KMail notice the change and popup you a dialog, asking an address (and subject)
- Click Send and that's all !!
Think it's a good way.
Idem : create and edit a text file in Nedit/emacs/vim and save it : mail is
directly send !!

That's all.
I hop to not have bored you :-D

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]