Why KDE4 is called KDE?

[Draciron Smith]

On Sat, Dec 12, 2009 at 8:03 AM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> On Friday, 2009-12-11, Draciron Smith wrote:
>> On Fri, Dec 11, 2009 at 6:05 AM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
>> > On Friday, 2009-12-11, Draciron Smith wrote:
>> Actually Kevin I'm one of the ones who's talking about adding items :)
>> One of my biggest gripes about KDE 4's panel and menu system.
>
> Maybe a misunderstanding then.
> In your other post you complained about menu editor not *finding* programs,
> int can certainly add new ones.

Actually that functionality didn't exist in the versions I was trying.
Wasn't until I got a recent update that menu editor had that
functionality though it doesn't work in the current revision I'm
using. I am able to browse too the file, even setup an icon, I hit
save and it acts like it was saved but no menu entry was created. This
I suspect is a bug that'll be fixed in the next update. It is exactly
the functionality I was looking for and one of my main questions when
I first joined the list.


> I have yet to see a shell which has built-ins for "gg:" or "leo:" or "dict:"
> or "kde:" or "wp:" or "imdb:" or "qt:"

You'd have to create a shell script for it, which would take about the
same time as setting up a bookmark in krunner long as you didn't get
fancy with it.

> I have also yet to see a shell which autocompletes kmail when I type mail or
> autocompletes kmail with a recepient as an argument when I type the name of a
> person in my address book.

Opening Kmail from the console is easy. It's even in the path. The
sender though that would be one thing you couldn't easily do from a
console window. So that's one thing.

> Shells are really good at completing executable names, directory names,
> quickly switching to directories, quickly copying/moving files, etc.

Aye for many file operations it really doesn't make sense to use a
GUI. If I want to wipe out all my mp3 files after converting them to
Oggs, actually a mass conversion to Oggs is something easier at the
console level than GUI then cleaning up the mp3s afterwards again it's
very simple from the command line and take seconds  but would take
more time and effort.  You'd have to sort by extention, scroll to the
top mp3, select that one, scroll down to the bottom and shift and
select then delete and say yes I want to delete. I could have cleared
10 dirs of mp3s in the same time it takes a single one in the GUI. If
you accidentlly launch the playing of 15,000 mp3s well then it takes a
WHOLE lot longer LOL.

I personally spend about %10-%20 of my time in the console. Depends on
what I'm doing with given machines. Some days I might spend more than
half my time in console windows and I go whole days without touching
one. Just on average I spend around a 5th of my time in a console
window. I could use Krunner instead but it's a kinda awkward interface
for how I work. The singularity of it is especially probmatic. I can
launch dozens of apps from the same console window, krunner goes away
after use. It's a one shot platform I'd have to open 100s of times a
day and the few things that are not doable and or easier from a
console are stuff I'm not doing anyway. eg Kevin's example of
launching Kmail to send an email. I typically use Kmail to archive
email and use a web interface for sending.


>> msvcrt.dll is one of a couple files that MUST be installed for a
>> Visual C++ compiled app to run. It's literally a run time lib, the
>> name even stands for microsoft visual C run time. VC is not truely a
>> compiled language.
>
> I think it is just a runtime link dependency, e.g. like Qt for a KDE program
> or libstdc++ for a C++ program.

Nope it's a run time lib. Take a hex editor too it sometime. You'll
find your prototypes and I'm not sure if it's even possible to create
a VC program even a console app without vcrt. With QT you are
leveraging outside libs, If your writing a console app or using GTK or
WX or one of several other graphics/GUI libs you can leave QT out
completely. Only apps that use the QT libs need to have QT present as
a dependency. Remember Windoze is a monolithic world. Depedencies are
almost invariably compiled into the code and or project. Except for
run time libs such as you find with VB/VC and so on. Not sure if .Net
uses the same scheme or if it's finally a compiled language but I
doubt M$ would abandon an idea they've stuck with for 30+ years now.

I think this is one of the key reasons VC apps are blown away in terms
of speed by just about any other compiler to ever go toe to toe with
VC.


>> OS's live and die on the compilers. Apple did the right thing making
>> it easy to write Iphone apps. If you had to wait for Apple to write
>> the apps the Iphone would have never really caught on I think. So the
>> more the avg Joe is able to write software the more software will be
>> out there, the more software the more chances of that killer must have
>> app being written, which means more people on that platform which
>> means more people writing software and so on.
>
> I think the first platform to get this right, even before Apple with iPhone,
> was Mozilla, i.e. allowing extensions to be written with just JavaScript and
> XML/HTML/CSS files.
> One could do full applications with their XUL runner framework as well, but I
> think the key is additions and customizations.

Mozilla's crew were ingencious with allowing that easy level of
modification. At least if they beat Opera too the punch. I wasn't
using Opera when the Mozilla plugins started happening but they've
been around for a bit and I suspect that particular innovation came
from Mozilla. Many other features such as tabbed browsing origionted
with Opera not Mozilla. I remember initially being skeptical but soon
found Opera's tabs very useful though Mozilla did a better job of
implementing them in terms of usability. The Tab manager in Mozilla is
still primitive and buggy and I usually replace it as one of the first
plugins I install.

I agree whole heartedly that a great deal of the success Mozilla is
enjoying is because of that extensivility. Every other major browser
in the world has since tried to copy it. Even IE is now doing the
plugin thing. However they jumped in too little too late.

The more configurable and the more customization you offer the more of
an edge any platform has, whether desktop manager or browser or OS.
It's a crucial aspect of design and things that wipe out customization
and configurability are a clear step backwards.

KDE has some ideas that I've heard tossed around like virtual desktops
and activities which sound very promising. The ability to have a panel
& desktop specific too an activity is a huge advancement conceptually
and really does make a workspace just that. You'll have all the tools
necessary for very specialized tasks at hand without cluttering up
your workspace with tools for other tasks.

A few key things. First it has to actually work :) Features that don't
work never do anybody any good :) It has to be easy to use. The more
of a pain it is too set something up the less likely it is to be used.
 People will gladly take a performance hit in terms of CPU for
features that honestly save them large amounts of time as the virtual
desktops/activities features promise too do.

The last is you need to build upon what you have. Radical changes
often wipe out good products. Going back to Turbo Pascal. It was a
leading language until they changed over too the TPUs and left no easy
covnersion. TP dropped dramatically in popularity and the Borland team
kept making radical changes in TP until almost nobody was still using
it. Once they morphed into Delphi and stabilized things then Pascal
came back as a viable language but in the long run Borland hurt
themselves deeply by taking their flagship product and leaving their
users lost in the dust of change that was often change for change's
sake.  You see lots of other good products that did the same thing.
Look at how quickly Dbase lost market share when they shipped a buggy
product that lost a great deal of backwards compatibility and stripped
some functionality out while adding "cutting edge features". Sure the
features they added would have been great if they didn't have a nasty
habit of formatting portions of your hard drive LOL. What happened
when people had to relearn everything as it was all either done
differently or moved around was that people tried other products. If
you have to relearn it and your old code base has to be converted why
not go too something cheaper and more backwards compatable like
Clipper and Foxbase right? That's what people did. Soon Dbase went
from being THE Xbase product to just one of the Xbase products not
even a leader.


> The availability of a high performance JavaScript interpreter in Qt (through
> WebKit's script core) will hopefully bring such options to more KDE apps in
> the future.

Konquerer already has some, though you have to learn from other folks
mistakes as well. VBscript for example was put into I think EVERY M$
app even if it made no sense to have it or even sometimes when it
wasn't exposed at all too end users through the UI of that app. That
didn't mean it couldn't be leveraged even when it was supposedly
turned off at the app level to take advantage of security flaws.

Think about it, %90 of Mozilla's serious security problems involve
Javascript, either itself or it gives a remote attacker the ability to
reach a flaw. Javascript is infinnitely more secure than VBscript
which doesn't even have  a sandbox, but enabling Javascript in many
apps makes no sense from a practical standpoint and puts them at great
risk security wise. Anything dealing with system administration should
not be javascript enabled for that reason. Anything that can take a
root password becomes a bait and switch opportunity for a remote
hacker.  When it comes to Koffice, checking your email,  file utils
like Krusader and Dophin, text editors, and so on yes I agree, you
could see some very useful plugins developed.  If you allow admin
tasks to be javascript enabled your begging for security woes on the
scale of a windoze machine.  Needs to be a whole separate design and
premise and Javascript's sandbox will need major enhancements before
you can try using it with admin apps. You'll also need too introduce
the concept of spheres. That is plugins launched from a user context
are shut down and restarted if the user moves too another user context
especially root. For example you open up yumex, as soon as you are
asked for the root pw all plugins should be shut down and only
restarted after the root pw is given. Their data cache should be
cleared and their cookies should be based on root dir cookies to
prevent data from leaking back and forth between user context through
cookies, temp files and memory (both cache an physical).

That kind of ability doesn't exist in Javascript at the moment.  Until
it does you can't allow certain apps to be javascript enabled.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.