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

List:       kde-i18n
Subject:    Re: konqueror components
From:       Teodor Romeo Mihai <teddy () piercom ! ie>
Date:       1999-02-16 14:27:05
[Download RAW message or body]

Waldo Bastian wrote:
> 
> Simon Hausmann wrote:
> > (this way it'd be possible for apps to create their own kfm views and "add"
> > them to konqueror (here as KfmMainView) . For example KMail might provide a
> > kmail-kfm-view to process mails "inside" konqueror when browsing the web)
> > In addition I think we might add a fourth (fifth?) part kfm view which does
> > nothing else than embedding other apps parts (for apps not wanting to "use" a
> > common kfmview parent interface) .
> 
> Intro
> =====
> I am trying to create a picture of how Konqueror should look like in KDE
> 2.0.
> If such a picture is clear, it is easier to build Konqueror such that it
> will
> feel like a consistent piece of software. This is of course only my view
> of
> the things. If someone has other views please let this know. It will
> help if
> a sort of common idea about the future of Konqueror exists.
> 
> KDE 2.0
> =======
> I think we should keep Konqueror a "browser": You can browse with it,
> and look
> at things. But when you want to _DO_ things, you will need a
> full-fledged
> application.
> 
> So you can view HTML with it.
> You can view directories with it.
> You can view text-files with it (read-only). (basically kless)
> You can view images with it.
> You can view mail-folders with it.
> You can view newsgroups with it.
> You can view xxx....
> 
> When you want more advanced manipulating options, modify things, or
> create
> things (writing a mail for instance) the "Real (tm)" application should
> pop
> up with its own menubars etc.
> 
> There is of course a thin line between viewing and modifying. With the
> file
> browser you want to be able to move/rename/delete files. So if we allow
> this functionality for file-browsing, we should also allow it for
> mail-browsing
> or news-browsing. (e.g. move/delete message cq. postings).
> 
> Creating does not really belong in a browser (apart from directories)
> because
> you will almost always need an application for this anyway. I seldom go
> to
> a directory to select "create xyz". Most of the time you start an
> application
> to create "xyz" and when you are done, you think of a nice place to
> store it.
> (I think Microsoft wants us to believe otherwise, with their "document-
> orientated" Windows95 marketing) ((Well, sometimes you are browsing and
> have
> a sudden urge to put a text-file like README in a directory. But for
> that
> you still need a text-editor. Just creating an empty file is of little
> use.))
> 
> Why is this important?
> ======================
> There must be a clear distinction between what can be done with
> Konqueror and
> what can be done with the application self. If there is no distinction
> we
> don't need Konqueror.
> 
> Smooth integration
> ==================
> With this Konqueror thing we have to tell the user a thing or two. We
> have to
> tell the user what he/she is doing: "Viewing a text-file", "Viewing a
> web-page",
> "Viewing a FTP-site", "Viewing e-mail". Because the options available to
> the
> user, depend on what he is doing: You can reply to e-mail. But you can't
> reply to a FTP-site. You can sort the entries of a FTP directory, but
> you
> can't sort a web-page.
> 
> At the same time, we have to tell the user that he/she is "Viewing". If
> you
> want to edit the web-page, the web-editor comes up. If you want to reply
> to the e-mail, the mail-composer comes up. At that time the user is
> editing/
> changing/modyfying.
> 
> >From the users point of view, the "viewing" part is konqueror. The
> editing
> part is the application.
> 
> >From the developers point of view, this can be different. The view
> e-mail
> mode of Konqueror could (but it doesn't have to) be handled by the same
> instance
> of kmail as the "edit" mode of kmail. If this will be indeed the case
> should
> depend on programming considerations.
> 
> What should not depend on programming considerations, is how it is
> presented
> to the user.
> 
> Discussion please?
> 
> Cheers,
> Waldo
> --
> KDE, Making The Future of Computing Available Today
> http://www.kde.org


Well, I've been working for a few months now on a Outloook-clone for
KDE, handling mail/contacts/schedule/journal/notes/groups. It is a bit
different from all KDE applications I've seen, being very close to
Outlook in look&feel rather than KMail - which I find unusable.
If you are seriously planning to put mail in kfm, maybe you should
consider some kind of integration with an external mailer, in
Explorer/Outlook style.

Regards,
 teddy

-- 
--------------------------------------------------------------------------------
Teodor Romeo Mihai  [email: teddy@piercom.ie]
Development Systems Engineer at Piercom Ltd.
Eurotechnopole Building, Holland Road
National Technological Park, Limerick
Ireland
Tel. +353 61 201972     Fax + 353 61 335051

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