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