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 it into /usr/local. <br>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). <br>
<br>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. <br><br>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. <br>
<br>Thanks for your help<br>Abhinav. <br><br><div class="gmail_quote">2009/11/5 <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: 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>><br>
Subject: Re: Qt KDE integration in kdereview.<br>
To: <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>
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 (not KDE<br>
> > > ones) to get better integration into KDE.<br>
> ><br>
> > How about integrating KDE widgets directly into pure Qt applications?<br>
> ><br>
> > I see that QMainWindow::menuBar(), QMainWindow::statusBar() and<br>
> > QMainWindow::addToolBar(QString) can be hacked. Maybe that plugin can<br>
> > provide the menu/statusbar/toolbar "virtual constructors" or 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. However, one of<br>
the most missing features for me in QToolBars are the icon/text 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>><br>
Subject: Re: Attica moved to kdereview<br>
To: <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>
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 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 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 together your<br>
> struct will use less memory<br>
Done.<br>
> Should downloadUrlDescription(), previewPicture(), license(), 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 if for<br>
> example it makes no sense that the application ever calls<br>
> Folder::setMessageCount it should be private and called by a friend class.<br>
> But maybe it makes sense calling Folder::setMessageCount and it's ok :D<br>
Since we support creating items and sending them to the server 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 supposed to be<br>
> part of the public API or not. Their headers are installed an the classes<br>
> exported, but<br>
><br>
> GetJob(const QSharedPointer<Internals>& internals, const 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 instances of<br>
these classes back from Attica::Provider. Constructors changed to 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>><br>
Subject: Re: device-automounter moved to kdereview<br>
To: <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>
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 manually adding<br>
> > > > > > > to the list) to use the feature.<br>
> > > > > ><br>
> > > > > > I believe we need to get rid of the UDIs and provide some more<br>
> > > > > > not just user-friendly, but "human-friendly" strings.. Having to<br>
> > > > > > deal with them even in some cases is not really 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 device, it<br>
> > > > > really really helps to figure out what we are talking about even<br>
> > > > > before we start reading.<br>
> > > > ><br>
> > > > > The volume property info.product is quite uninformative (usually<br>
> > > > > Volume(ext3)), but if you jump back to the closest relative which<br>
> > > > > has a info.product property you will find quite interesting things,<br>
> > > > > such as ExpressCard, or stuff like that.<br>
> > > > ><br>
> > > > > Then I'd compose a string with the following field (with 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 (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... MicroSD<br>
> > > > > is the volume label)<br>
> > > > ><br>
> > > > > Still, as you can see there's room for improvement, in particular<br>
> > > > > the second guy was giving quite debatable information 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 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 shown with<br>
> > > vendor() and product() and total size (should be available with<br>
> > > storage.removable.media_size) and then each child (partition) would<br>
> > > just show description() and size This is visually better since it<br>
> > > removes redundant information for partitions of the same drive. and<br>
> > > makes it easier to browse.<br>
> > ><br>
> > > On the other hand, if a volume is an only child, then don't 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 already<br>
> > > present in the .rc file whenever possible; besides; who is responsible<br>
> > > to fill in the devices in the .rc file? the daemon I suppose; would it<br>
> > > be possible to save the pretty name we have found for our device at the<br>
> > > daemon level? so that whenever you connect the drive, the user would<br>
> > > find it with its pretty name in the disconnected devices node as well.<br>
> > > Having it set up at the daemon level could make the kcm part 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; 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 undo the<br>
> otherwise permanent memorization of "automount this device because 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 makes much<br>
> > sense. Also i tried to change Automount on login and Automount 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. Also,<br>
> those two fields only change when the device list is rebuilt. I'm thinking<br>
> I should build a model specifically for the KCM so that the updating of<br>
> this is done when the checkboxes are toggled, and it'd be a lot 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>
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>><br>
Message-ID:<br>
<<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>><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><br>
Message-ID: <<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 seems to<br>
> because of nepomuk.<br>
> i downloaded soprano-2.3.1 from <a href="http://sourceforge.net" target="_blank">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] 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 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 altogether?<br>
> If not, then how can I solve the above problem? Do I need to 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>><br>
Subject: Re: Qt KDE integration in kdereview.<br>
To: <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>
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. 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 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 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 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>><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><br>
Message-ID: <<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 platform<br>
> plugin (cf the thread from Olivier) could even use that when 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>><br>
Subject: Re: Qt KDE integration in kdereview.<br>
To: <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>
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>> 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 not set<br>
> > >> > yet?<br>
> > >><br>
> > >> That wouldn't be a bad idea either, it's easier just to 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 what we<br>
> > want.<br>
><br>
> True.<br>
> And I just realized that it wouldn't help making sure KDEHOME is 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 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 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>><br>
Subject: Re: Rocs moved to kdereview.<br>
To: <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>
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><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>
</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>