more intuitive visual interface

[Juergen Suessmaier]

> > If you wrote a MyListBox that only had functionality that you need,
> > it would likely be smaller.
> 
> I see, yes, I did misunderstand that.
Ok, that's correct from a single program's point of view and only if
code size is really an issue. It _is_ an issue for example on small
embedded systems where you've got a certain amount of EPROM space
into which you have to fit your program. If your code is larger then
you've got a real problem.

On the other hand when writing software for "regular" workstation
users, the philosophy of highly optimized code won't work that well
in practice. If you've got some real powerful libraries like Qt, which
in addition is used as a shared lib by a lot of programs, then you'll
get (and in fact your do get) double benefit. First you speed up development
drastically by using common well tested shared libraries -even if they
provide a lot more code than your specific application will use, and
second you'll preserve a reasonable amount of memory as these shared
libs are loaded only once. Just assume each KDE tool and KDE itself
used it's own optimized container or widget classes, then you'd have
dozens of implementations basically doing the same job. I think it is
somewhat guaranteed that dozens of those classes take much more memory
and disk space than one single general purpose "bloated" one does. So
in fact you do preserve memory resources plus you'll save hours and days
of implementation, debugging and testing time in this case.

> > Especially if it were based upon your own generic classes. I'm not
> > saying Qt is bad I'm just saying that
> > it will tend to produce larger binaries than stuff that's home grown
> > lean and mean.
> 
> Like  Gtk+? Hey, just kidding... :-) 
Well, it always depends on the environment - see above. The multithreaded
lib of Qt 2.3 needs about 5 Meg of memory. If you are running a single
application under a non-KDE window manager, the statement is true without
any doubt. Even a "do nothing" Qt application will load this shared lib
into memory - very expensive for this case. But if your application runs
within a "normal" KDE environment, each other KDE app will just use this
once loaded lib - as well as KDE itself...

> > I think he was trying to say the empolyee was incompetent. Your
> > second sentence above insinuates that
> > the writer of the post is also incompetent. My impression is that he
> > is at least fairly competent.
> 
> No no, I apologize sincerely if that is the way my statement was
> understood. I am in no way to make any judgements about the original
> posters competence whatsoever. What I was meaning to say was, that the
> *employer* seems to be fairly unreliable, firing people for something
> that is so simple to fix. The person in question had already shown the
> ability to learn something, so why not retrain him to teach him what
> pointers to functions are, that concept is really not difficult to
> understand, no reason to fire someone. 
Well, business is sometimes somewhat tough :-( In times where a lot of
software guys apply for a single job, the "hire and fire" method will
match the business interests quite well. If you can get an experienced
developer for the same money as you'd have to pay for a newbie, then
it would be quite stupid (from the management's point of view) not to
hire the expert. In times where it is really hard to find experts, it
would be stupid to fire the newbie - assuming that he is willing to and
able to learn new things. This is the short-term view of business. Long
term it could be better to train the newbie until he matches the requirements
as this also enforces the employee's loyality towards the company.
Probably a weak assumption but I personally do also count on an employee
as a human being as I think it makes a big difference between having
people who feel responsible and are part of the company and those
people who just sell a fixed amount of time. Of course this all depends
on how critical your business actually is, but also less experienced
folks can do great jobs - for example by supporting your gurus in helping
them do the less interesting but simpler parts of the project(s). This
could also give advantages as the highly experienced folks can concentrate
on the "hard" parts while the newbies doing the "boring" stuff (which
isn't that much boring from their point of view). That way you could
save expensive expert resources and you'll educate the people who will
become the experts one year or two later.

Well, again, this is basically a matter of mentality, philosophy and
of course economic environment.

Best regards,
Juergen
-- 
-------------------------------------------------------------------------
J. Süßmaier Systementwicklungen
Jürgen Süßmaier
juergen at suessmaier.de                       Realtime Software Development
Katharina Geisler Str. 14                       Embedded Applications
D-85356 Freising                                     Automation
Germany
-------------------------------------------------------------------------
                      http://www.suessmaier.de
-------------------------------------------------------------------------
      The day Microsoft makes something that doesn't suck is
        probably the day they start making vacuum cleaners
-------------------------------------------------------------------------

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«