[Sebastian Treug] Problems compiling kdebase-4.3 due to trig

Sebastian TrĂ¼g trueg at kde.org
Tue Nov 10 10:54:29 GMT 2009


Please state the actual problem again as the email history does not seem to 
contain it...

On Monday 09 November 2009 23:16:21 Abhinav Chaturvedi wrote:
> Hi Sebastian,
> I tried what you suggested. And this is what I got:
> 
> redland-config --version = 1.0.8
> raptor-config --version = 1.4.18
> rasqal-config --version = 0.9.16
> 
> Attached are 2 files:
> 1. CMakeCache.txt file in the build folder one needs to create before
> compiling Soprano
> 2. CMakeLists.txt file from ../build
> 
> I see options like SOPRANO_DISABLE_RAPTOR_PARSER:BOOL=OFF in
> the CMakeCache.txt file. So I am thinking that everything that is needed
> should have been compiled from scratch. Did I miss something when doing
> 'cmake'?
> 
> Thanks
> Abhinav.
> 
> 
> 2009/11/10 <kde-core-devel-request at kde.org>
> 
> > Send kde-core-devel mailing list submissions to
> >        kde-core-devel at kde.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        https://mail.kde.org/mailman/listinfo/kde-core-devel
> > or, via email, send a message with subject or body 'help' to
> >        kde-core-devel-request at kde.org
> >
> > You can reach the person managing the list at
> >        kde-core-devel-owner at kde.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of kde-core-devel digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re: Review Request: startup faster;       don't wait for kwin or
> >      kcm's in ksmserver (Lubos Lunak)
> >   2. Re: chess and barcelona (Marco Martin)
> >   3. Re: [Sebastian Treug] Problems compiling kdebase-4.3 due to
> >      trig (Sebastian Trueg)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 9 Nov 2009 14:56:33 +0100
> > From: Lubos Lunak <l.lunak at suse.cz>
> > Subject: Re: Review Request: startup faster;    don't wait for kwin or
> >        kcm's in ksmserver
> > To: kde-core-devel at kde.org
> > Message-ID: <200911091456.33717.l.lunak at suse.cz>
> > Content-Type: text/plain;  charset="utf-8"
> >
> > On Saturday 07 of November 2009, Sebastian Sauer wrote:
> > > > On 2009-11-04 10:10:06, Lubos Lunak wrote:
> > > > > The reason for waiting for the WM to finish setup is not the
> >
> > fallback,
> >
> > > > > but making sure the WM is ready. There are some aspects related to
> > > > > window management where applications just read the status during
> >
> > their
> >
> > > > > startup and don't update later. So waiting for the WM ensures this
> > > > > is set up properly before other applications may read that
> > > > > (although, thinking of that, this is currently a bit broken anyway,
> > > > > as KWin lets ksmserver continue a bit too soon).
> > > > >
> > > > > The second case is something similar. The kcminit modules do
> > > > > various setup and it is a question if it is ok to let normal apps
> > > > > start while this is still taking place.
> > >
> > > Specs are relative. Cold start (not initial) takes up to 9 seconds till
> >
> > the
> >
> > > plasma desktop is visible / ksplashx closes.
> >
> >  Hmm. Twice 1/2s is not that insignificant then :-/.
> >
> > > The thing is that the wm starts very early. Even before plasma which
> > > does not need the wm at this point. The first "real" applications are
> > > rather late started/restored. Maybe we should just wait in
> > > KSMServer::autoStart1Done() till the wm is ready? Would that be enough?
> >
> >  Plasma is not different from other applications in this regard, in fact,
> > it
> > may depend more on it - compositing status, number of virtual desktops,
> > etc.
> > I have no idea what would happen if e.g. Plasma thought there was just 1
> > virtual desktop because it saw that too soon.
> >
> > > The kde startup process has lot of potential for optimizations.
> >
> >  It is intentionally designed that way. The original application
> > launching code (around KSMServer::tryRestoreNext()) is written to launch
> > apps one by one. IIRC the reason for that was that computers[*] of those
> > days were bad at
> > handling the load and putting sleeps here and there actually improved the
> > overall situation. I doubt anyone has benchmarked this in a reasonably
> > recent
> > time.
> >
> > [*] Or maybe we could blame the kernel.
> >
> > > Time
> > > expensive things like e.g. kcminit are atm blocking the whole startup.
> >
> > Long
> >
> > > term we need to have expensive things run in parallel at startup.
> > > Anyway, if you think that this is not a good idea then it should be
> > > maybe done another way.
> >
> >  I don't know if there is another way. The code can be changed to launch
> > normal apps in parallel if that helps, there would be no problem with
> > that. But the rest currently has certain ordering (see ksmserver/README)
> > with some
> > implications. For example startup phase 0 (i.e. Plasma) is done quite
> > early and waited for completion in order to have the desktop ready, hide
> > the splash
> > and give the impression that the desktop or more or less ready while
> > normal apps are still being loaded. Moving things one way can mean the
> > splash is shown needlessly long when the desktop could be already usable,
> > opposite way
> > would be showing desktop that is still not usable (as is the case with
> > some Windows versions and AFAIK it's rather annoying).
> >
> >  If you would have some time to spend on this, it would be interesting if
> > you
> > could analyze the KDE startup as a whole and see where the time is spent
> > (note: cold vs warm disk caches did tripple the number when I tested that
> > the
> > last time, so pay attention to that). With that thinking about doing some
> > rearranging should be simpler.
> >
> > --
> > Lubos Lunak
> > KDE developer
> > --------------------------------------------------------------
> > SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
> > Lihovarska 1060/12   tel: +420 284 084 672
> > 190 00 Prague 9      fax: +420 284 028 951
> > Czech Republic       http://www.suse.cz
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Mon, 9 Nov 2009 17:22:02 +0100
> > From: Marco Martin <notmart at gmail.com>
> > Subject: Re: chess and barcelona
> > To: kde-core-devel at kde.org
> > Message-ID: <200911091722.02201.notmart at gmail.com>
> > Content-Type: Text/Plain;  charset="iso-8859-1"
> >
> > On Sunday 08 November 2009, Albert Astals Cid wrote:
> > > A Diumenge, 8 de novembre de 2009, Inge Wallin va escriure:
> > > > On Sunday 08 November 2009 20:56:20 Albert Astals Cid wrote:
> > > > > A Diumenge, 8 de novembre de 2009, Frank Karlitschek va escriure:
> > > > > > Hi,
> > > > > >
> > > > > > as a favor for Quim Gil from Maemo I forward two things to you
> >
> > which
> >
> > > > > > might be interesting.
> > > > > >
> > > > > >
> > > > > > 1. The Maemo people are doing a "UX meets Code" Hackfest in
> >
> > Barcelona
> >
> > > > > > in December.
> > > > > > All KDE people are invited. Please see this page if you are
> > > > > > interested to participate.
> > > > > > http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend
> > > > > >
> > > > > >
> > > > > > 2. Quim is looking for developers to help with a Qt 4.6 based
> > > > > > chess game for Maemo.
> > > > > > Check this page if you want to help:
> > > > > > http://wiki.maemo.org/Miniature
> > > > >
> > > > > You want kde-games-devel at kde.org for KDE games developers, but not
> >
> > sure
> >
> > > > >  people there is interested in doing Qt/Maemo development, since
> > > > > it's really not KDE development after all.
> > > >
> > > > I think this reasoning is wrong.  KDE is not just the desktop
> >
> > environment
> >
> > > >  any more, it's the toolkit, including kdelibs and the community.
> > > > Nowadays KDE applications are cross platform, and the more we can get
> > > > into the mobile devices and make our apps run on small form factors
> > > > the better.
> > > >
> > > > Development for Maemo is just our next frontier.
> > >
> > > We disagree here :-)
> > >
> > > As part of the KDE community I care the less for Maemo until it ships
> >
> > KDE,
> >
> > >  it shipping Qt is cool because means i have knowledge to code for it
> > > if
> >
> > i
> >
> > >  feel like, it gives me more job opportunities, and probably creates
> > > more
> >
> > well, the opportunity for Maemo to ship KDE should also be created, if we
> > don't push it i doubt that will happen any day, if we show that using
> > kdelibs
> > there besides Qt can have clear advantage could instead make it happen,
> > and being on a potentially successful smartphone platform is indeed
> > -very- interesting
> >
> > Cheers,
> > Marco Martin
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Mon, 09 Nov 2009 19:57:12 +0100
> > From: Sebastian Trueg <trueg at kde.org>
> > Subject: Re: [Sebastian Treug] Problems compiling kdebase-4.3 due to
> >        trig
> > To: kde-core-devel at kde.org
> > Message-ID: <4AF86608.6020801 at kde.org>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Abhinav Chaturvedi wrote:
> > > Hi Sebastian,
> > > I cannot seem to find which version of libredland and libraptor I have.
> > > But what I can tell you is that I downloaded Soprano-2.3.1 and compiled
> > > it into /usr/local.
> >
> > redland-config --version
> > should help here.
> >
> > > It is this Soprano that I then used during kdebase compilation. I was
> > > compiling KDE-4.3.3 on an OpenSuse-11.1 system (which has KDE-4.1.x).
> > > For now, I have managed to compile kdebase by disabling Nepomuk
> > > compilation (BUILD_nepomuk:BOOL=OFF in CMakeCache.txt).
> >
> > Could you get the cmake output from your own Soprano compilation to me?
> >
> > > I don't know whether there is any connection between Soprano and
> > > Nepomuk. So, i don't know whether you can infer redland and raptor
> > > versions from the Soprano version number.
> >
> > Nepomuk is based on Soprano.
> >
> > > But if you could tell me of a way to find the redland and raptor
> > > versions, then I'll hurry the answers back to you.
> > >
> > > Thanks for your help
> > > Abhinav.
> > >
> > > 2009/11/5 <kde-core-devel-request at kde.org
> > > <mailto:kde-core-devel-request at kde.org>>
> > >
> > >     Send kde-core-devel mailing list submissions to
> > >            kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >
> > >     To subscribe or unsubscribe via the World Wide Web, visit
> > >            https://mail.kde.org/mailman/listinfo/kde-core-devel
> > >     or, via email, send a message with subject or body 'help' to
> > >            kde-core-devel-request at kde.org
> > >     <mailto:kde-core-devel-request at kde.org>
> > >
> > >     You can reach the person managing the list at
> > >            kde-core-devel-owner at kde.org
> > >     <mailto:kde-core-devel-owner at kde.org>
> > >
> > >     When replying, please edit your Subject line so it is more specific
> > >     than "Re: Contents of kde-core-devel digest..."
> > >
> > >
> > >     Today's Topics:
> > >
> > >       1. Re: Qt KDE integration in kdereview. (Diego Iastrubni)
> > >       2. Re: Attica moved to kdereview (Frederik Gladhorn)
> > >       3. Re: device-automounter moved to kdereview (Albert Astals Cid)
> > >       4. Re: Bugreporting barrier is too low with the new Dr. Konqi
> > >          (Dar?o Andr?s)
> > >       5. Re: [newbie]: Problems compiling kdebase-4.3 due to trig
> > >          (Sebastian Tr?g)
> > >       6. Re: Qt KDE integration in kdereview. (Olivier Goffart)
> > >       7. Re: KDE is not an OS platform... (And neither is Gnome)
> > >          (Alexander Neundorf)
> > >       8. Re: Qt KDE integration in kdereview. (Alexander Neundorf)
> > >       9. Re: Rocs moved to kdereview. (Tomaz Canabrava)
> >
> > ----------------------------------------------------------------------
> >
> > >     Message: 1
> > >     Date: Wed, 4 Nov 2009 21:07:11 +0200
> > >     From: Diego Iastrubni <elcuco at kde.org <mailto:elcuco at kde.org>>
> > >     Subject: Re: Qt KDE integration in kdereview.
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <200911042107.11986.elcuco at kde.org
> > >     <mailto:200911042107.11986.elcuco at kde.org>>
> > >     Content-Type: Text/Plain;  charset="iso-8859-1"
> > >
> > >     On Tuesday 03 November 2009 21:11:21 David Faure wrote:
> > >     > On Tuesday 03 November 2009, Diego Iastrubni wrote:
> > >     > > On Tuesday 03 November 2009 17:55:51 Olivier Goffart wrote:
> > >     > > > Hello.
> > >     > > >
> > >     > > > I have just submitted a new plugin in kdereview:
> > >     > > > qguiplatformplugin_kde
> > >     > > >
> > >     > > > The objective of this plugin is to allow pure Qt Application
> > >
> > >     (not KDE
> > >
> > >     > > > ones) to get better integration into KDE.
> > >     > >
> > >     > > How about integrating KDE widgets directly into pure Qt
> > >
> > >     applications?
> > >
> > >     > > I see that QMainWindow::menuBar(), QMainWindow::statusBar() and
> > >     > > QMainWindow::addToolBar(QString) can be hacked. Maybe that
> > >
> > >     plugin can
> > >
> > >     > >  provide the menu/statusbar/toolbar "virtual constructors" or
> > >
> > >     something.
> > >
> > >     > You mean in order to create KMainWindows and KToolBars?
> > >     > What would this provide to the Qt applications?
> > >
> > >     making a KMainWindow, from a QMainWindow should be difficult.
> > >     However, one of
> > >     the most missing features for me in QToolBars are the icon/text
> > >     settings and
> > >     the lock toolbars command.
> > >
> > >     I am just thinking aloud: how hard can this be?
> > >
> > >
> > >
> > >     ------------------------------
> > >
> > >     Message: 2
> > >     Date: Wed, 04 Nov 2009 20:12:06 +0100
> > >     From: Frederik Gladhorn <gladhorn at kde.org
> > > <mailto:gladhorn at kde.org>> Subject: Re: Attica moved to kdereview
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <4af1d3da.0f1abc0a.68f4.3f25 at mx.google.com
> > >     <mailto:4af1d3da.0f1abc0a.68f4.3f25 at mx.google.com>>
> > >     Content-Type: text/plain; charset="ISO-8859-1"
> > >
> > >     Hola Albert,
> > >     thanks a lot for the review!
> > >     I hope that we addressed your points by now.
> > >
> > >     Albert Astals Cid wrote:
> > >     > A Dimarts, 3 de novembre de 2009, Frederik Gladhorn va escriure:
> > >     >> Hi all,
> > >     >> after spending some time with libattica, we decided that now is
> > >     >> a
> > >
> > >     good
> > >
> > >     >>  point to get a review for it and eventually have it used in
> > >     >> KDE.
> > >     >
> > >     > The licensing is unclear, activity.h is GPL2+ while
> > >     > downloaditem.h
> >
> > is
> >
> > >     > LGPL2+
> > >
> > >     Done, we forgot to make it the same everywhere, it's relicensed to
> > >     LGPL2+ in
> > >     agreement with all authors now.
> > >
> > >     > You have one foreach without const & in the "iterator"
> > >
> > >     /me hides :D
> > >
> > >     > Maybe it would make sense to d-pointify Attica:BaseJob::Metadata,
> > >     > Attica::DownloadUrlDescription, Attica::GetJob, Attica::PostJob
> > >
> > >     Mostly done, will be finished tomorrow.
> > >
> > >     > In Attica::DownloadUrlDescription if you put the two bools
> > >
> > >     together your
> > >
> > >     > struct will use less memory
> > >
> > >     Done.
> > >
> > >     > Should downloadUrlDescription(), previewPicture(), license(),
> > >
> > >     author() of
> > >
> > >     > Attica::Content be const?
> > >
> > >     Done.
> > >
> > >     > Should url() in Attica::DownloadItem be const?
> > >
> > >     Yes.
> > >
> > >     > Any reason to make Attica::DownloadItem use a
> > >     > QExplicitlySharedDataPointer?
> > >
> > >     Total nonsense and an oversight by me.
> > >     Seems like I wasn't quite awake when writing that class...
> > >
> > >     > From the application point of view, it would make sense to me
> > >     > that
> > >
> > >     if for
> > >
> > >     > example it makes no sense that the application ever calls
> > >     > Folder::setMessageCount it should be private and called by a
> > >
> > >     friend class.
> > >
> > >     > But maybe it makes sense calling Folder::setMessageCount and it's
> > >
> > >     ok :D
> > >     Since we support creating items and sending them to the server
> > >     again, most
> > >     setters make sense. The case you asked about is indeed
> > > questionable.
> > >
> > >     > After a quick look at the API i'm not sure if the Jobs are
> > >
> > >     supposed to be
> > >
> > >     > part of the public API or not. Their headers are installed an the
> > >
> > >     classes
> > >
> > >     > exported, but
> > >     >
> > >     > GetJob(const QSharedPointer<Internals>& internals, const
> > >
> > >     QNetworkRequest&
> > >
> > >     > request);
> > >     > seems a bit weird, what's that QSharedPointer<Internals>?
> > >
> > >     Yep, this is supposed to be used only internally. You just get
> > >     instances of
> > >     these classes back from Attica::Provider. Constructors changed to
> > >     private or
> > >     protected now.
> > >
> > >     Thanks!
> > >
> > >     Greetings
> > >     Frederik
> > >
> > >
> > >     ------------------------------
> > >
> > >     Message: 3
> > >     Date: Wed, 4 Nov 2009 20:41:56 +0100
> > >     From: Albert Astals Cid <aacid at kde.org <mailto:aacid at kde.org>>
> > >     Subject: Re: device-automounter moved to kdereview
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <200911042041.56630.aacid at kde.org
> > >     <mailto:200911042041.56630.aacid at kde.org>>
> > >     Content-Type: Text/Plain;  charset="iso-8859-15"
> > >
> > >     A Dimecres, 4 de novembre de 2009, Trever Fischer va escriure:
> > >     > On Tuesday 03 November 2009 6:18:43 pm Albert Astals Cid wrote:
> > >     > > A Dimarts, 3 de novembre de 2009, Jacopo De Simoi va escriure:
> > >     > > > On Tuesday 03 November 2009 02:15:20 Trever Fischer wrote:
> > >     > > > > On Monday 02 November 2009 6:45:18 pm Jacopo De Simoi wrote:
> > >     > > > > > On Monday 02 November 2009 23:56:14 Jacopo De Simoi wrote:
> > >     > > > > > > > So you /don't / have to use UDIs (unless you're
> > >
> > >     manually adding
> > >
> > >     > > > > > > > to the list) to use the feature.
> > >     > > > > > >
> > >     > > > > > > I believe we need to get rid of the UDIs and provide
> > >
> > >     some more
> > >
> > >     > > > > > > not just user-friendly, but "human-friendly" strings..
> > >
> > >     Having to
> > >
> > >     > > > > > > deal with them even in some cases is not really
> > >
> > >     acceptable. I'll
> > >
> > >     > > > > > > try to have a look into this to see how we can sort
> > >     > > > > > > this
> >
> > out
> >
> > >     > > > > > Just quickly playing with the solid minibrowser I have a
> >
> > few
> >
> > >     > > > > > suggestions
> > >     > > > > >
> > >     > > > > > First of all, show whichever icon solids give to the
> > >
> > >     device, it
> > >
> > >     > > > > > really really helps to figure out what we are talking
> > >
> > >     about even
> > >
> > >     > > > > > before we start reading.
> > >     > > > > >
> > >     > > > > > The volume property info.product is quite uninformative
> > >
> > >     (usually
> > >
> > >     > > > > >  Volume(ext3)), but if you jump back to the closest
> > >
> > >     relative which
> > >
> > >     > > > > > has a info.product property you will find quite
> > >
> > >     interesting things,
> > >
> > >     > > > > > such as ExpressCard, or stuff like that.
> > >     > > > > >
> > >     > > > > > Then I'd compose a string with the following field (with
> > >
> > >     parent I
> > >
> > >     > > > > > mean the closest device in the hierarchy which has the
> >
> > infos
> >
> > >     > > > > > required)
> > >     > > > > >
> > >     > > > > > parent.info.vendor parent.info.product
> > >     > > > > > volume.info.product
> > >
> > >     (size)
> > >
> > >     > > > > > Some real-life examples:
> > >     > > > > >
> > >     > > > > > Seagate FreeAgent Go Backup_HD (160 Go)
> > >     > > > > > ST325082 0A MediaHD (250 Go)
> > >     > > > > > Lexar ExpressCard ssdhome (5 Go)
> > >     > > > > > Lexar ExpressCard ssdroot (3 Go)
> > >     > > > > > SD02G Volume (ext3) (2 Go) (with SD icon)
> > >     > > > > > Kingston FCR-HS219/1 MicroSD (2 Go) (I'm cheating here...
> > >
> > >     MicroSD
> > >
> > >     > > > > > is the volume label)
> > >     > > > > >
> > >     > > > > > Still, as you can see there's room for improvement, in
> > >
> > >     particular
> > >
> > >     > > > > > the second guy was giving quite debatable information
> > >
> > >     about itself
> > >
> > >     > > > > > (however still better than
> > >     > > > > > /org/freedesktop/Hal/devices/volume_uuid_ECBF_30CC)
> > >     > > > >
> > >     > > > > Nonetheless a good idea. I added it to the GUI.
> > >     > > >
> > >     > > > Ok, now this looks much better; what about this, now, to make
> > >
> > >     it look
> > >
> > >     > > > even better;
> > >     > > >
> > >     > > > If (and only if) there exists more than one volume with the
> >
> > same
> >
> > >     > > > parent, group them with the parent; then the parent will be
> > >
> > >     shown with
> > >
> > >     > > > vendor() and product() and total size (should be available
> > >     > > > with storage.removable.media_size) and then each child
> > >     > > > (partition)
> > >
> > >     would
> > >
> > >     > > > just show description() and size This is visually better
> > >     > > > since
> >
> > it
> >
> > >     > > > removes redundant information for partitions of the same
> > >
> > >     drive. and
> > >
> > >     > > > makes it easier to browse.
> > >     > > >
> > >     > > > On the other hand, if a volume is an only child, then don't
> > >
> > >     add another
> > >
> > >     > > >  node and use the long description we talked about yesterday.
> > >     > > >
> > >     > > > Also, imho the informations should be refreshed even if it's
> > >
> > >     already
> > >
> > >     > > >  present in the .rc file whenever possible; besides; who is
> > >
> > >     responsible
> > >
> > >     > > > to fill in the devices in the .rc file? the daemon I suppose;
> > >
> > >     would it
> > >
> > >     > > > be possible to save the pretty name we have found for our
> > >
> > >     device at the
> > >
> > >     > > > daemon level? so that whenever you connect the drive, the
> > >     > > > user
> > >
> > >     would
> > >
> > >     > > > find it with its pretty name in the disconnected devices node
> > >
> > >     as well.
> > >
> > >     > > > Having it set up at the daemon level could make the kcm part
> > >
> > >     merely
> > >
> > >     > > > read it from the .rc since it will be automagically updated.
> > >     > > >
> > >     > > > Moreover, I believe that the Add device button is useless;
> > >
> > >     nobody would
> > >
> > >     > > >  really enter the udi of a device.
> > >     > >
> > >     > > I agree here, and the forget device is not of much use either
> > >     >
> > >     > The reason I put it in was I figured there needs to be some way
> > >     > to
> > >
> > >     undo the
> > >
> > >     > otherwise permanent memorization of "automount this device
> > >     > because
> > >
> > >     it has
> > >
> > >     >  been mounted before".
> > >     >
> > >     > > > Nice job!
> > >     > > > @Albert, what  do you think about the ui fixes?
> > >     > >
> > >     > > The list let's you do multiple selection, i don't think that
> > >
> > >     makes much
> > >
> > >     > >  sense. Also i tried to change Automount on login and Automount
> > >
> > >     on attach
> > >
> > >     > >  from No to Yes on my pendrive but wasn't able to do it.
> > >     >
> > >     > Multiple selection lets you forget more than one device at a
> > >     > time.
> > >
> > >     Also,
> > >
> > >     >  those two fields only change when the device list is rebuilt.
> > >     > I'm
> > >
> > >     thinking
> > >
> > >     >  I should build a model specifically for the KCM so that the
> > >
> > >     updating of
> > >
> > >     >  this is done when the checkboxes are toggled, and it'd be a lot
> > >
> > >     cleaner
> > >
> > >     >  than just a qstandardmodel.
> > >
> > >     Ok, makes sense, thanks for the clarification.
> > >
> > >     Albert
> > >
> > >     > > Albert
> > >
> > >     ------------------------------
> > >
> > >     Message: 4
> > >     Date: Wed, 4 Nov 2009 17:14:03 -0300
> > >     From: Dar?o Andr?s <andresbajotierra at gmail.com
> > >     <mailto:andresbajotierra at gmail.com>>
> > >     Subject: Re: Bugreporting barrier is too low with the new Dr. Konqi
> > >     To: KDE-Devel <kde-core-devel at kde.org
> > > <mailto:kde-core-devel at kde.org
> > >
> > >     Message-ID:
> > >            <a2c126ef0911041214n5613e97cv2ff945f1994cb28f at mail.gmail.com
> > >     <mailto:a2c126ef0911041214n5613e97cv2ff945f1994cb28f at mail.gmail.com
> > >
> > >     Content-Type: text/plain; charset=ISO-8859-1
> > >
> > >     Ok, I have currently implemented some features in order to improve
> >
> > the
> >
> > >     situation:
> > >
> > >     - The duplicate list that DrKonqi provides should be smarter and a
> >
> > bit
> >
> > >     smaller (as it uses a stricter query to bugzilla)
> > >     - The duplicate list now includes the bug status in a tag, with
> > >     no-jargon (ex ."[Open]", "[Fixed]", "[Already Reported]",
> >
> > "[Invalid]")
> >
> > >     - When you want to open a possible duplicate report, if that report
> > >     "X" is already marked as duplicate of another report "Z", you can
> > >     choose to show the report you wanted to open ("X") or the main
> > > report ("Z") <- Resolving nested duplicate levels
> > >
> > >     Other fixes that I have coded but I haven't commited yet:
> > >
> > >     - If there are possible duplicates listed and the user didn't
> >
> > selected
> >
> > >     anyone, nor marked anyone to attach the new information to it, a
> > >     messagebox will appear asking if he is sure.
> > >
> > >     - In the description step, if the user haven't entered a proper
> >
> > amount
> >
> > >     of input, the user is *forced* to do so (we need to discuss the
> >
> > amount
> >
> > >     of characters to be considered good input) (the user already
> > > selected the checkbox "I can provide information about the crash"). If
> > > the
> >
> > user
> >
> > >     doesn't accept this, the dialog is closed (but a warning about the
> > >     dialog being closed appears, if the user changes his/her mind...)
> > >
> > >     In both messages I'm explicitly saying that not following this
> >
> > advices
> >
> > >     will *waste* the time of the KDE developers and triagers, so at
> > > least they can think a bit before sending pseudo-crap. (yes, the text
> > > needs to be improved, may be it is too harsh...)
> > >
> > >     Screenshots of earlier implementation of this features:
> > >
> > >     http://imagebin.ca/view/XY3uu1W.html
> > >     http://imagebin.ca/view/i2-0cQ.html
> > >     http://imagebin.ca/view/0jSX7VP.html
> > >
> > >     I would like to get some feedback about all this things
> > >
> > >     Thanks in advance.
> > >     Regards
> > >
> > >     Dar?o A.
> > >
> > >
> > >     ------------------------------
> > >
> > >     Message: 5
> > >     Date: Wed, 4 Nov 2009 21:32:09 +0100
> > >     From: Sebastian Tr?g <trueg at kde.org <mailto:trueg at kde.org>>
> > >     Subject: Re: [newbie]: Problems compiling kdebase-4.3 due to trig
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <200911042132.09880.trueg at kde.org
> > >     <mailto:200911042132.09880.trueg at kde.org>>
> > >     Content-Type: Text/Plain;  charset="iso-8859-15"
> > >
> > >     which version of libredland and libraptor do you have installed?
> > >
> > >     On Tuesday 03 November 2009 22:58:14 Abhinav Chaturvedi wrote:
> > >     > Hi all,
> > >     >
> > >     > I am having problems compiling kdebase (of KDE-4.3 branch) and
> > >     > its
> > >
> > >     seems to
> > >
> > >     > because of nepomuk.
> > >     > i downloaded soprano-2.3.1 from sourceforge.net
> > >
> > >     <http://sourceforge.net>, compiled it and installed
> > >
> > >     > it in /usr/local.
> > >     > Hence, when I do cmakekde in kdebase, I get the following
> > >     > message:
> > >     >
> > >     >
> > >     > Found Soprano Plugin Dir: /usr/local/share/soprano/
> > >     > plugins/soprano/plugins
> > >     > -- Found Soprano Plugins: nquadparser nquadserializer
> > >     > raptorparser raptorserializer redlandbackend sesame2backend
> > >     >
> > >     > There is no 'trig'. I am assuming there should be a parser for it
> >
> > like
> >
> > >     >  there are for raptor, redland etc.
> > >     > And that this parser should have been included in Soprano-2.3.1.
> >
> > But
> >
> > >     > apparently it is not. Which is why
> > >     > I get the following message when compiling kdebase.
> > >     >
> > >     > [ 10%] Generating nie.h,
> > >     > nie.cpp
> > >     >
> > >     > Could not find parser plugin for encoding
> > >     > trig
> > >     >
> > >     > make[2]: *** [runtime/nepomuk/strigibackend/nie.h] Error
> > >     > 1
> > >     > make[1]: ***
> > >     > [runtime/nepomuk/strigibackend/CMakeFiles/sopranobackend.dir/all]
> > >
> > >     Error
> > >
> > >     > 2
> > >     > make[1]: *** Waiting for unfinished
> > >     > jobs....
> > >     >
> > >     > Linking CXX executable
> > >     > knotify4
> > >     >
> > >     > [ 10%] Built target
> > >     > knotify
> > >     >
> > >     > make: *** [all] Error 2
> > >     >
> > >     >
> > >     > I was wondering if you have seen this problem before. I must tell
> > >
> > >     you that
> > >
> > >     >  I did *not* checkout anything other
> > >     > than kdepimlibs, kdebase, kdelibs and phonon. These were enough
> >
> > when I
> >
> > >     >  tried compiling KDE-4.3 some
> > >     > months back.
> > >     >
> > >     > Is there anyway in which I can bypass 'nepomuk' compilation
> > >
> > >     altogether?
> > >
> > >     > If not, then how can I solve the above problem? Do I need to
> > >
> > >     checkout some
> > >
> > >     > other KDE packages?
> > >     >
> > >     > Thanks for your help
> > >     > Abhinav.
> > >
> > >     ------------------------------
> > >
> > >     Message: 6
> > >     Date: Wed, 4 Nov 2009 22:33:21 +0200
> > >     From: Olivier Goffart <ogoffart at kde.org <mailto:ogoffart at kde.org>>
> > >     Subject: Re: Qt KDE integration in kdereview.
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <200911042133.21442.ogoffart at kde.org
> > >     <mailto:200911042133.21442.ogoffart at kde.org>>
> > >     Content-Type: Text/Plain;  charset="iso-8859-1"
> > >
> > >     Le Wednesday 04 November 2009, Diego Iastrubni a ?crit :
> > >     > making a KMainWindow, from a QMainWindow should be difficult.
> > >
> > >     However, one
> > >
> > >     >  of the most missing features for me in QToolBars are the
> > >     > icon/text settings and the lock toolbars command.
> > >     >
> > >     > I am just thinking aloud: how hard can this be?
> > >
> > >     Regarding the icon/text settings in a QToolBar:
> > >     - The default icon size is read from the KDE config for the default
> > >     KDE icon
> > >     size in toolba
> > >     - The default text position is read from the KDE config if using
> > >     Qt::ToolButtonFollowStyle  as QToolBar::toolButtonStyle  (new in
> > >     4.6, we could
> > >     not make it the default because it was a too huge behaviour change)
> > >
> > >     There is currently no plan to support being able to edit QToolBar
> > > as KDE does.
> > >
> > >
> > >
> > >     ------------------------------
> > >
> > >     Message: 7
> > >     Date: Wed, 4 Nov 2009 21:53:25 +0100
> > >     From: Alexander Neundorf <neundorf at kde.org <mailto:neundorf at kde.org
> > >
> > >     Subject: Re: KDE is not an OS platform... (And neither is Gnome)
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <200911042153.25201.neundorf at kde.org
> > >     <mailto:200911042153.25201.neundorf at kde.org>>
> > >     Content-Type: text/plain;  charset="iso-8859-1"
> > >
> > >     On Wednesday 04 November 2009, David Faure wrote:
> > >     > On Wednesday 04 November 2009, nf2 wrote:
> > >     > > * But Qt-only apps?
> > >     > >
> > >     > > And i do believe Qt is quite important for getting more apps
> >
> > written
> >
> > >     > > for the FOSS desktop. As its portability is very attractive.
> > >     >
> > >     > OK, that's a good point. However QFile/QDir is not the answer
> > >     > IMHO. Qt has a nice API for async networking requests already:
> > >     > QNetworkAccessManager (for which we have a KIO backend; the
> > >     > qt-kde
> > >
> > >     platform
> > >
> > >     > plugin (cf the thread from Olivier) could even use that when
> > >
> > >     kdelibs is
> > >
> > >     > around).
> > >     > But for file dialogs, it misses directory listing, and stat, at
> >
> > least.
> >
> > >     I think QAbstractFileEngine comes quite close, you can use to to
> > > plug in "virtual" filesystems based on URLs into Qt apps, including the
> >
> > file
> >
> > >     dialog.
> > >
> > >     Alex
> > >
> > >
> > >     ------------------------------
> > >
> > >     Message: 8
> > >     Date: Wed, 4 Nov 2009 21:59:54 +0100
> > >     From: Alexander Neundorf <neundorf at kde.org <mailto:neundorf at kde.org
> > >
> > >     Subject: Re: Qt KDE integration in kdereview.
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID: <200911042159.54853.neundorf at kde.org
> > >     <mailto:200911042159.54853.neundorf at kde.org>>
> > >     Content-Type: text/plain;  charset="iso-8859-1"
> > >
> > >     On Wednesday 04 November 2009, David Faure wrote:
> > >     > On Wednesday 04 November 2009, George Kiagiadakis wrote:
> > >     > > On Wed, Nov 4, 2009 at 3:19 AM, David Faure <faure at kde.org
> > >
> > >     <mailto:faure at kde.org>> wrote:
> > >     > > > On Wednesday 04 November 2009, Michael Pyne wrote:
> > >     > > >> On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:
> > >     > > >> > Maybe startkde could set KDEHOME to localprefix if it is
> > >
> > >     not set
> > >
> > >     > > >> > yet?
> > >     > > >>
> > >     > > >> That wouldn't be a bad idea either, it's easier just to
> > >
> > >     always have
> > >
> > >     > > >> KDEHOME set than special-casing it.
> > >     > > >
> > >     > > > Yep, excellent idea.
> > >     > >
> > >     > > No, bad idea. If you are using both kde3 and kde4 apps and you
> >
> > want
> >
> > >     > > them to use different KDEHOMEs, setting KDEHOME in startkde is
> >
> > just
> >
> > >     > > going to force them both to use the same KDEHOME, which is not
> > >
> > >     what we
> > >
> > >     > > want.
> > >     >
> > >     > True.
> > >     > And I just realized that it wouldn't help making sure KDEHOME is
> > >
> > >     always
> > >
> > >     > set, since one can also run kde apps outside of a kde workspace
> > >     > (->
> >
> > no
> >
> > >     > startkde run).
> > >     >
> > >     > > That's why the KDE4_DEFAULT_HOME cmake variable exists.
> > >     >
> > >     > Yeah but that's not introspectable.
> > >     > Hmm, actually, it is:  `kde4-config --localprefix`, but calling a
> > >
> > >     process
> > >
> > >     > probably too slow for doing from Qt?
> > >
> > >     Hmm, if it's done once on application startup it might be
> > > acceptable.
> > >
> > >     It's also saved in
> > >     share/apps/cmake/modules/KDELibsDependencies.cmake, in the
> > >     KDE_DEFAULT_HOME variable.
> > >     You can basically rely on the format of that line:
> > >     set(KDE_DEFAULT_HOME ".kde")
> > >     So without really parsing it just matching a regexp should do.
> > >
> > >     Alex
> > >
> > >
> > >     ------------------------------
> > >
> > >     Message: 9
> > >     Date: Wed, 4 Nov 2009 20:48:04 -0200
> > >     From: Tomaz Canabrava <tumaix at gmail.com <mailto:tumaix at gmail.com>>
> > >     Subject: Re: Rocs moved to kdereview.
> > >     To: kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     Message-ID:
> > >            <7ebbb4b50911041448g42da8498gf938ec5aae8436f8 at mail.gmail.com
> > >     <mailto:7ebbb4b50911041448g42da8498gf938ec5aae8436f8 at mail.gmail.com
> > >
> > >     Content-Type: text/plain; charset=ISO-8859-1
> > >
> > >     Ok, I'v managed to fix 2 crashes, workarounding a well known
> > >     qt-problem on trees & graphicsview.
> > >     it shoudn't crash no more.
> > >
> > >     and improved the showing of the properties of the nodes and edges.
> > >
> > >     tomorrow I will do nothing ( beach time ), but I plan to have
> > >     everything that anyone say here fixed by next sunday.
> > >
> > >
> > >     ------------------------------
> > >
> > >     _______________________________________________
> > >     kde-core-devel mailing list
> > >     kde-core-devel at kde.org <mailto:kde-core-devel at kde.org>
> > >     https://mail.kde.org/mailman/listinfo/kde-core-devel
> > >
> > >
> > >     End of kde-core-devel Digest, Vol 80, Issue 27
> > >     **********************************************
> > >
> > >
> > >
> > >
> > > --
> > > It's the peoples' will, I am their leader, I must follow them. (Jim
> > > Hacker in Yes Minister)
> >
> > ------------------------------
> >
> > _______________________________________________
> > kde-core-devel mailing list
> > kde-core-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-core-devel
> >
> >
> > End of kde-core-devel Digest, Vol 80, Issue 43
> > **********************************************
> 




More information about the kde-core-devel mailing list