[kubuntu-devel] Project Timelord -- Initial consideration

[Yuriy Kozlov]

On Thu, Oct 22, 2009 at 10:23 AM, Jonathan Riddell <jriddell at ubuntu.com> wrote:
>
> That has the obvious downside that when KDE suck we suck too, not
> having a decent network connection tool is a collective failure of KDE
> because it's something every desktop environment should have, but it
> hit us hard being the ones who deliver KDE to users.  The transition
> to KDE 4 has been a problem for us because of some similar cases like
> that where KDE has fallen behind.  It's probably my Quaker idealism
> but I do think that sticking to KDE is the best way to make a rocking
> free software desktop in the long term, rather than using Gnome or
> distro-proprietary tools as other distros do, because KDE is the best
> platform.  In that respect I'm entirely against using Gnome-esque apps
> like Synaptic or Firefox.  Network manager could be a different case,
> we include proprietary drivers because without them some people
> couldn't use their computer, so the same could be said there, however
> I think we're over the worse for that.

I completely agree with this.  I think sticking to pure KDE is one of
the things that sets Kubuntu apart.  One thing you did not mention
explicitly that I think this policy brings Kubuntu is a clear and
strong development platform, one of the key goals of KDE4.  This is
both necessary to become a popular consumer operating system and is
expected of one.  With KDE+Qt Kubuntu has a very strong (unrivaled?)
development platform and I think adding any parallel technologies to
the default install dilutes that.  In very rare cases such as
NetworkManager, using the Gnome applet for one or two releases may
have been the right choice because critical functionality was broken
for almost everyone.  However, I think we should be very wary of
opening the floodgates to diluting the vision, consistency, and
development platform that Kubuntu offers.  It seems to me that the
timing for Lucid is just right with all the KDE 4 stuff coming
together (assuming k3b moves anywhere at all in the next 6 months and
knetworkmanager continues at the current pace; kpackagekit may be the
exception), so I think this would be a very bad time to stray from the
Qt/KDE-only policy.

Of course anything I say on this is somewhat moot because I use
aptitude on the command line for package management.


> Marketing
I think the Timelord project is right on with what needs to be done
for branding.  The pre-KDE4 releases had excellent visual identity and
it would be great to go back to that in the form of adding a Kubuntu
touch to the Oxygen/Air artwork.  The first priority for Lucid artwork
I think should be a Kubuntu KDM theme.  Not having the name of the
operating system on the login screen is just weird.

>
> Handling bug reports
> ==
> I put off using apport for KDE apps because I suspected we didn't have
> enough triagers and most bugs (should) come from upstream.  Using
> apport was a bit of an experiment and we can easily enough go back to
> using drkonqi if we want.  Getting sensible backtraces is the tricky
> thing with drkonqi, anyone know if the download-debug-symbols for it
> materialised?
I put up some discussion points on this here:
https://wiki.kubuntu.org/Kubuntu/Bugs/Apport/Discussion
Basically my opinion on it is that apport still makes sense long-term,
but we(I?)'ve dropped the ball on recruiting triagers and that needs
to be fixed.

> Kubuntu application integration
> ==
>
> software-properties isn't being dropped by Ubuntu Desktop, it's still
> being used including in their new software centre.
If Ubuntu is still mostly maintaining it, I think it could use some
KDE-ifying UI work, but that is low priority.

>
> I don't think rewriting printer-applet in c++ is feasable (we havn't
> completed the system-config-printer port even using the same
> language), but there is some code missing compared to the gtk one to
> stop it loading all python-kde libraries at startup which we should
> look into.
>
> update-notifier-kde should use notifications rather than systray icons
> for sure (although presistent notifications in KDE have no indication
> that they are linked to the "i" systray icon but that's a UI issue for
> upstream).  re-writing in C++ would be possible but a lot of work for
> not too much gain.
I think rewriting these utilities in C++ would be nice long-term but
should be done on a look-i-have-code basis.  Jonathan and Harald have
already gotten pretty far on the new update notifier so it would be
nice to have that for Lucid.  I've actually been doing a "killall
python" on every login on Feisty.

~ Yuriy