[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Requiring KApplication because of installX11EventFilter (was Re:
From:       Benjamin Meyer <ben () meyerhome ! net>
Date:       2009-05-05 19:00:06
Message-ID: 2167B46C-7B51-47FB-802D-E3A269267ABB () meyerhome ! net
[Download RAW message or body]


On May 5, 2009, at 1:46 PM, Aaron J. Seigo wrote:

> On Tuesday 05 May 2009, Benjamin Meyer wrote:
>> In the end I could run KDE4 apps on top of QApplication.
>
> yes, one _can_ but there are still things in KApplication that give  
> some
> harmony across KDE apps like a consistent entry on the session bus
> (setApplicationName, setOrganizationName), the x11 start up id stuff,
> registration of KUrl as a metatype, checking writability of config,  
> rtl
> awareness, some platform dependent stuff (e.g. the tray icon on a  
> mac) ...
>
> i'm not expecting all of these things to magically go into Qt, but  
> they do
> make KApplication, at least for gui apps, not quite optional without  
> running
> into either inconsistencies or a lot of code dupe.
>
> what it does mean, of course, is that our widgets and other  
> libraries should
> never, ever use KApplication internally anymore as they have no need  
> to
> (KComponentData ftw! :). only the actual executable applications  
> should ever
> see / require this class.

I want to say that I made a static function that was in KAppication  
which did many of those KDE type things you mentioned.  I want to say  
you could do something like:

QApplication app;
KApplication::init();

The key was really that there didn't need to have a kApp instance (and  
thus no segfaults) which was the real goal.  A lone static function  
that happen to reside in KApplication that setup all those kde stuff  
was what it was about.

-Benjamin Meyer
[prev in list] [next in list] [prev in thread] [next in thread]