Ideas for Student Projects

[Robert Knight]

> Just look at the menu items in Konqueror and then try to change _anything_.
> You'll get angry developers telling you why they have to have it that way,
> and another bunch of more friendly developers telling you that it is
> impossible to change.

Actually I think that on the whole, KDE developers are quite receptive
to the idea of change.  That was the feeling I got at aKademy this
year at least.  The problems of excess complexity in KDE is, for the
most part I think, accepted.  Of course there are pockets of
resistance, but I think they can be dealt with by:

a)  Avoiding discussing usability issues on lists like this one which
are primarily aimed at developers, but going through the KDE usability
project's lists instead.
b)  Make more use of actual HCI research in UI designs, as opposed to
speculation about how users interact with the software.  See the
reports which the KDE usability team have been working hard on over
the past few years.

> The only concepts that are hard to understand for a java
> developer are pointers and the need to free memory that you have allocated
> (and thus also that there are two different ways to create objects).

In practise though C++ has many subtleties which take a while to
learn, and more importantly, has none of the nice runtime safety nets
which Java provides.  Qt code is relatively easy C++ to work with
though - so it is a good introduction.

Regards,
Robert.

On 09/02/07, Kenneth Wimer <kwwii at bootsplash.org> wrote:
> On Friday 09 February 2007 13:15:20 Reinhold Kainhofer wrote:
> > Am Freitag, 9. Februar 2007 schrieb Scott Wheeler:
> > > On Wed, 7 Feb 2007 01:52:26 +0100, Reinhold Kainhofer wrote:
> > > > Furthermore, the prof used Linux on his desktop, but not KDE, because
> > > > GNOME looked way more polished and gave him the impression that Gnome
> > > > was years ahead of KDE.
> > >
> > > ...but then complained that it was a little hard to use after switching
> > > away from using OLWM on his SPARC when IT took it away last month.
> > > "Netscape has changed a lot," he noted.  ;-)  (Or in other words,
> > > unless CS professors have changed drastically in the last few years,
> > > they're hardly incidators of current trends in desktop usage.)
> >
> > Actually, he is not one of the old-school CS profs (I once sent a
> > S/MIME-signed mail to such an old-school CS prof, and the response I got
> > was that the doesn't read emails that only contain attachments.... Quite
> > embarrassing for him.)
> > The guy I talked to was a young associate prof, who switched to Mac from
> > Linux on the desktop, and uses Linux on his servers. He's also an open
> > source developer for Cocoon, btw.
> > I would actually say, he is quite representative for the stuff that CS is
> > heading to.
> >
> > And I have to admit, that I fully agree with him. KDE might be absolutely
> > top-notch as far as technology is concerned, but the UI (in particular the
> > config dialogs) don't look clean and easy at all. Rather, they simply offer
> > hundreds of options to the user, most of which he'll not need anyway, and
> > those that are needed are often hard to find.
> >
> > Now, I'm not saying we should go the GNOME road and simply through out most
> > of the options. I'd rather see things really cleaned up and rearranged in a
> > way that our plethora of options is not confusing any more.
> >
>
> Rearranging the thousand different options is not going to make anything
> simpler/better. The fact of the matter is that our config dialogs are
> mainly "by developer, for developer".
>
> Just look at the menu items in Konqueror and then try to change _anything_.
> You'll get angry developers telling you why they have to have it that way,
> and another bunch of more friendly developers telling you that it is
> impossible to change.
>
> > > > Now, I'm looking for some KDE project ideas that I can propose for that
> > > > contest. [...]
> > >
> > > http://wiki.kde.org/tiki-index.php?page=KDE%20Google%20SoC%202006%20ideas
> > >
> > > There are quite a few leftovers.
> >
> > These are almost exclusively coding projects (and some are out of date or
> > already implemented, I suppose). I was mainly looking for some
> > non-purely-coding projects (artwork, UI polishing, work on HCI guidelines
> > and maybe their implementation, cleaning up configs etc.)
> >
>
> as far as HCI (artwork, usability accesability) we can certainly use all the
> help we can get. Can't think of any specific ideas at this time, but there
> are certainly a few out there.
>
> > > > The other possibility would be topics for bachelor or master theses
> > > > or other lab projects. The problem is just that the students hardly
> > > > know C++ [...]
> > >
> > > People often mention this, but it's not like C++ was a standard
> > > teaching language for more than a few years.  It was kind of a stopover
> > > language in the late 90s on the way from Pascal to Java.  All things
> > > considered, it's a lot easier to learn C++ coming from Java than most
> > > languages.
> >
> > I totally agree. The only concepts that are hard to understand for a java
> > developer are pointers and the need to free memory that you have allocated
> > (and thus also that there are two different ways to create objects).
> >
> > Cheers,
> > Reinhold
>
> Ken
>