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

List:       kde-devel
Subject:    Re: Could Kant replace or extend KWrite in KDE ?
From:       Phlip <pplumlee () omnigon ! com>
Date:       2001-02-24 19:26:25
[Download RAW message or body]

Proclaimed Thorsten Schnebeck from the mountaintops:

> ... hmm ... maybe I should first compile Kant, so now I argue about a
> screenshot ;-)
> (Few) little questions: What is the intension of this user interface?
> Why do you have an embedded terminal? In konqi you have a kind of
> path-following, so there a embedded terminal is valuable - but where is
> such a value in kants user interface? What is the value of multiple files
> _in_ kants workspace? Do you have synched scrollbars like in Cervisia or
> multi-viewing (here top, there end of the same doc)?

I veiw kant as reaching out to touch two areas. One is the KWrite/Notepad/vi 
niche - the default editor for a Desktop. As such (if our TODO list gets 
done) it will pop up quickly with few dependencies or load-time binary reads, 
and have very few gimmicks on its window besides your text and a menu bar. 
But it will have a >complete< set of editor keystrokes, not the 
Mac/Windows/Notepad derivative KDE seems to have inherited via rumor.

The other area should be "the editor you live in". It should be customizable 
to do your keystrokes the way you like them, to read the kinds files you 
often edit, and to shell to a compiler to compile those files. This is where 
the KWrite part, with its (beautiful) syntax highlighting, obviously wants to 
go. The editor should not couple to any kind of compiler, but it should have 
a clear and simple way to register build commands, and it should filter the 
output of those commands looking for error messages to display.

> I know it is easy to integrate feature with KDE/QT libraries - but we are
> going in a wrong direction: programs with more and more nifty features. Do
> you remember: MS-Word has an buildin graphic editor, an Exel-lite
> spreadsheet and so on. Do you like this? I call this bloadware!

We are not trying to compete with KDevelop. Put that another way: We are 
trying to compete with KDevelop by not doing the bloatware and coupling 
things it does. We are UI-first; we integrate with a specific compiler as a 
"plugin" feature, not a precondition of deigning to let the user run us the 
first time.

Unlike MS Word, we should not promote a monolithic "intent" upon our users. 
But, like MS Word, we should support KDE "part" architecture to plug-and-play 
other elements in the KDE suite. And, unlike MS Word, ONLY if the user asks 
for them!

> Programmers are often bad gui-designers. (No - emacs is also not an example
> for good gui-design ;-)

No! D'y'a think?

> but its more a developer tool than an enduser
> application) And this is the reason for the KDE developer style guide
> webpage!

I hope to fancy myself a GUI expert (and my employers have not grumbled about 
this conceit yet). Read our TODO list.

> If I take a second view of this screenshot kant looks like a rudimentary
> IDE not like a texteditor ... nor a replacement for kwrite.

I personally won't fret about KWrite continuing to occupy the KWrite niche, 
but I sincerely feel that our best features should at least be transfered 
into it.

-- 
  Phlip                          phlip_cpp@my-deja.com
============== http://phlip.webjump.com ==============
  --  Set phasers on illin'  --
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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