kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

Albert Astals Cid aacid at kde.org
Sun Aug 21 15:35:32 BST 2011

A Diumenge, 21 d'agost de 2011, John Layt vàreu escriure:
> On Saturday 20 Aug 2011 13:11:32 Oswald Buddenhagen wrote:
> > On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
> > > It needs a global spec too, since global shortcut grabbing with X11
> > > libs only is sorely lacking. I think the solution we made for KDE 4
> > > is actually quite good. Anyone wants to create an XDG spec for
> > > global accelerators?
> > 
> > well, yeah. good luck to whoever. :P
> We had a bad experience last time, but we should use that experience to play
> smarter this time around.  The big complaints that I saw from Gnome last
> time was that we supposedly had no clear statement of why the spec was
> needed and what it was meant to achieve, that they had no real involvment
> in the drafting of the spec, that we talked to the wrong people, and that
> it was something they didn't need in G3.
> So lets turn that on its head.  Lets write a statement saying why we need a
> spec and what it needs to achieve.  Mention we have an existing solution
> that would be a good starting point, but don't actually detail it.  Then
> send that to xdg and Gnome and Unity and anyone else asking who are the
> right pople to talk to.  Hopefully those people then decide it's a good
> thing and agree to work together to develop a standard.  If they're not
> interested then we get to draft it ourselves knowing there can be no
> complaints.
> > > But just as before, I don't see why our code can't be cross-desktop.
> > > So
> > > no argument in favour of dropping kglobalaccel.
> > 
> > i think it is pretty clear that our *code* is not going to be accepted
> > as the cross-desktop solution. seeing the reluctance to anything with g*
> > within our community, why do you think the gnomers would embrace
> > anything with a q* or even k*, esp. given that it usually weights in at
> > least twice as much as the typical g* solution?
> We depend on a lot of g code these days, some of it even willingly, and
> we're looking at even more.  As for Gnome never accepting any q/k code,
> it's mostly true, but copying is the sincerest form of flattery :-)  Can we
> actually point to cases where Gnome rejected Qt/KDE code proposals, and how
> about ones that have been accepted (Poppler?).

You really can not cound poppler as coming from "our side". Poppler was 
started and driven by Red Hat Desktop Team (or something similar) and it was 
not until they lost interest (aka Red Hat relocated people to work on a 
different project) that real easy collaboration started to happen.


> I'm not convinced it's really about the weight or otherwise of our solutions
> (system-config-printer is written in python!).  How much is just C vs C++,
> or our not pushing stuff, or just not having key people employed by the
> distros? I'd like to see what happens when Qt5 has a nice light QtCore that
> we use to write something small and light that they need.
> John.

More information about the kde-core-devel mailing list