[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