On 05/11/17 16:12, Michail Vourlakos wrote:
> Do you know any better way to handle this?
You can let cmake do the check:
https://cmake.org/cmake/help/v3.0/module/CheckSymbolExists.html
Not sure if this is the best option, though.
Greetings,
Sven
signature.asc
Description: OpenPGP digital sig
On 11/11/16 16:45, Dominik Haumann wrote:
> What do you think about having a Randa meeting (or similar) with focus
> on finishing ports to KF5? Would that make sense?
+1 actually. There are a few applications on that list which would, in
my eyes, be a real loss if they were not maintained any more;
Hey,
On 19/03/16 21:44, Dominik Haumann wrote:
> I think I will just say
> QDesktopServices::openUrl(doc->url().adjusted(QUrl::RemoveFilename));
> then for now.
KRun::runUrl seems to work fine as well.
Greetings,
Sven
signature.asc
Description: OpenPGP digital signature
On 03/02/2016 11:56 AM, Thomas Lübking wrote:
> Imo that's a more issue: IPC is I/O, ie. unreliable. You cannot provide
> functionality that relies on working IPC, but hard-relying on it is bad
> design (nb. that the failing kded module make _every_ Qt client using
> QSystemTray unusable and trying
Hey,
On 03/02/2016 11:19 AM, Martin Graesslin wrote:
> No, because everything in the current plugin is Plasma specific.
Meh. In some kind of theoretical view you are right, I do see that.
Pragmatically, that's just not true, most of the things in the plugin
are not plasma specific at all, for exam
Hey,
On 03/01/2016 07:37 PM, Mark Gaiser wrote:
> but there is
> undoubtedly going to be a point in time where the plugin only works when
> some very specific plasma part is required for it to function
That is already the case; try running an application with a systray
icon, it will not work (or i
On 02/29/2016 11:09 PM, Thiago Macieira wrote:
>> So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for
>> > any non-plasma desktop out there. Instead you are stuck with a 3rd party
>> > solution like qt5ct to at least set the Qt / icon theme (color scheme is
>> > quite hard alre
Hey,
On 02/28/2016 03:58 PM, Luigi Toscano wrote:
> This is what I use:
> export QT_QPA_PLATFORMTHEME=kde
>
> and you need the integration plugin installed. It used to be part of
> Frameworks (frameworksintegration), it will be part of Plasma (but hopefully
> still usable without).
It isn't, unf
On 08/12/15 10:54, Ben Cooksley wrote:
>> > Correction: Wayland is also affected. I didn't check a gmail mail. So given
>> > that all freedesktop.org are probably affected.
>> >
>> > Sorry Ben, that's just a no, it will be highly disruptive to KDE to turn us
>> > off from these mailing lists.
> Can
> N not scratch repos. I can see clones being useless as branches
> in the actual repos should be used instead, but I personally consider
> scratch repos a very useful thing, for example to host simple projects
> that shouldn't be part of any main/big module - they are much more
> easier to set
> Everyone with a KDE developer account should in principle have
> the right to give a +2. One should only use it when appropriate though, i.e.
> when one is the maintainer of a given piece of code or when the patch is
> simple enough so that one feels safe to give the other the ship-it.
That's my
Hi,
On Thursday 13 February 2014 22:04:32 Alexander Semke wrote:
> Huch. I cannot reproduce this. Does this error happens on your system
> independent of the plot type (box plot etc.) you're trying to create?
Sorry for the noise, I apparently didn't install the XMLGUI files properly.
Thus the butt
Hello!
On Tuesday 11 February 2014 21:32:29 Alexander Semke wrote:
> couple of days ago LabPlot-project [1] decided to move to KDE and to become
> a part of KDE Edu and to collaborate closer with people involved in other
> projects on KDE Edu [2]. After almost four years of development we had the
files opens them in the default application, as it should.
Thanks,
Sven Brauch
Hi!
Cool project, I really missed such a component a while back (I actually wrote
my own back then, which was less nice than yours). The code looks sane too
from a quick look, so I'm all for moving it to extragear (although I'm not
exactly an expert for sane code).
It doesn't seem to be design
On Monday 11 November 2013 14:13:22 Martin Gräßlin wrote:
> Please remember: do not push a revert of a merge commit.
Another tip not everyone might know: you can use
git push --dry-run
to see which changes would be pushed, without actually pushing them. That
helps a lot with avoiding breakage.
On Sunday 03 November 2013 12:49:52 henry miller wrote:
> Richard Hughes wrote:
> >Please don't portray me as a modern-day highwayman as I'm really just
> >trying to build an awesome application installer for GNOME. It's two
> >orders of magnitude harder to actually write a shared standard and ask
On Sunday 03 November 2013 13:50:05 Richard Hughes wrote:
> I don't think that's true at all. Krita and Inkscape are two of the
> killer apps I'd love to feature more prominently in GNOME Software.
Yes, and of course both applications would do anything it takes to get listed
in the package manage
On Sunday 03 November 2013 12:22:52 Richard Hughes wrote:
> This is what we've decided to do in GNOME, KDE is free to decide any policy
> it wants. We've decided that 500 high quality applications are better than
> 3000 broken ones.
Assuming KDE did that, then we would end up with a situation wher
On Saturday 02 November 2013 20:05:11 Richard Hughes wrote:
> > Who's doing the quality review?
> Well, if an upstream ships a valid .desktop file and a valid AppData
> file then that's a good indication it's at least alive.
I don't understand that. It's a good indication it's alive right now, but
On Saturday 02 November 2013 19:48:01 Richard Hughes wrote:
> On 2 November 2013 19:33, Albert Astals Cid wrote:
> > What's the point in having an installer that hides more than half of the
> > apps in the world that don't ship a file that is not a standard and
> > doesn't seem to me it was develo
On Saturday 02 November 2013 14:37:02 Richard Hughes wrote:
> Well, I've not done any technical review of the OCS code, but in
> Fedora I've chosen to use fedora-tagger for ratings and comments. It's
> not hardcoded and I'd be open to doing something else.
I have worked with OCS in the past on a te
rnal viewer),
> > Open (in the default application) or Open With... (any other application).
>
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try
> ;)
>
> How about a context menu action? Or, since the context
rnal viewer),
> > Open (in the default application) or Open With... (any other application).
>
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try
> ;)
>
> How about a context menu action? Or, since the context
click?
- Sven
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
-------
On Oct. 8, 2013, 3:23 p.m., Sven Brauch
org/r/113175/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83
Diff: http://git.reviewboard.kde.org/r/113175/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
http://git.reviewboard.kde.org/r/113175/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
r.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83
Diff: http://git.reviewboard.kde.org/r/113175/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
On Wednesday 21 August 2013 23:23:35 David Faure wrote:
> You could listen to the KDirNotify signal leftDirectory(url).
Awesome, thanks.
Hi!
On Wednesday 21 August 2013 22:37:31 David Faure wrote:
> No, which is why people typically create a kded module for the purpose of
> such always-running watching and notifying.
Ok, then this is probably what I'm going to do, too.
> I don't really follow this one. The URLs have to match as yo
Hi!
I'm writing a KIO slave for the infinote protocol [1]. The protocol features
push-notifications for connected clients when a file is added or removed, and
it's sort of important for the user to see when files are added. Thus, I'd
like to make the application using the slave (e.g. dolphin) r
I think Nuno's point is very interesting and worth thinking about. To
stick with the firefox example, since they started releasing every
ortography fix in the settings dialog as a new major version, I think
attention in the media to their releases has declined a lot -- nobody
cares any more that a
>> 2. GDK installs a deadly X error handler, causing the application to
>> exit, instead of "just" printing an error message. See multiple
>> backtraces containing gdk_x_error[3]
There have recently been similar reports for KDevelop, too.
> On June 16, 2013, 4:59 p.m., Sven Brauch wrote:
> > While speedup is certainly always great, this sounds dangerous to me:
> >
> > > I am getting an inconsistency. Using the unpatched fast mime detection on
> > > a file like: "test.tar.gz" gets detec
o those changes. In any case I
would vote against putting such a fundamental change in behaviour into the
soon-to-be-released 4.11 (without a long testing period).
I didn't look at the code.
- Sven Brauch
On June 16, 2013, 4:42 p.m., Mark Gaiser wrote:
>
> -
!
- Sven Brauch
On June 13, 2013, 5:10 p.m., Dominik Haumann wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
> If there are no objections, I'd remove the two pages mentioned above
> by the end of the week. What do you think?
I think I found those pages recently too, and I'm all for deleting
them. They will get out of date again, even if someone would update
them now.
Cheers!
Hi,
I'm sorry, but I have to agree with Anne-Marie.
Cheers!
Sven
2013/5/12 Anne-Marie Mahfouf :
> Hi,
>
> I think Kartesio is not ready to move:
> - the GUI is not so good
> - lack of tooltips
> - I am not happy with some strings and they lack context info
> - the standard C++ code is not so goo
Hi Luca,
> Yes, the correct way to express a power is ^. So you should write x^2.
I figured that after it had crashed ;)
> There should be a check routine to avoid that a dangerous string like
> "**" is used, and I'm surely integrating this check in the next release.
In my opinion you should not
Hey!
A good thing, I think such a tool could be useful to me too (and I
know a lot of other people to whom it might be useful). Here's what I
noticed from a quick look (some has been said already I think):
* You probably shouldn't track the kdev4 file in the repository, same
goes for screenshots
> On May 2, 2013, 10:15 a.m., Heiko Tietze wrote:
> > Of course the changes do improve the menu and I believe your proposal would
> > be helpful.
> >
> > But I would like to discuss the following points:
> >
> > * Adding a header to menus is not commonly used. And I'm not sure why I
> > need
Hi,
kdev-python has been moved to extragear.
https://projects.kde.org/projects/extragear/kdevelop/plugins/kdev-python
Thank you for your support.
Cheers,
Sven
2013/4/3 Albert Astals Cid :
> El Dimecres, 3 d'abril de 2013, a les 10:53:32, Sven Brauch va escriure:
>> Hi list,
>
Hi list,
kdev-python has been in kdereview for almost four months now, and
still no decision has been reached. Since I'm the person asking for
review, I can't decide anything.
What's the policy for a reviewed application when there's voices for
and against accepting it? If the application should b
version...
- Sven
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109568/#review29732
---
On March 22, 2013, 11:31 a.m
/uploaddialog_p.h 1bb0af4
Diff: http://git.reviewboard.kde.org/r/109568/diff/
Testing
---
Thanks,
Sven Brauch
ewboard.kde.org/r/109568/#review29671
---
On March 18, 2013, 5:41 p.m., Sven Brauch wrote:
>
> ---
> This is an automatically generated e-mail. To reply, vi
submitted now.
- Sven Brauch
On March 18, 2013, 5:41 p.m., Sven Brauch wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
Hi,
my patch to python [1] was merged recently, so I could start working
on porting kdev-python away from the python fork. [2] is a branch
which is up-to-date with master and works without the fork, it just
links against the system's python 3.4. It's not perfect yet, but
neither was the old python
/uploaddialog.h 3f58f7d
knewstuff/knewstuff3/uploaddialog.cpp 922469e
knewstuff/knewstuff3/uploaddialog.ui aa54d2b
knewstuff/knewstuff3/uploaddialog_p.h 1bb0af4
Diff: http://git.reviewboard.kde.org/r/109568/diff/
Testing
---
Thanks,
Sven Brauch
ile specified in .knsrc
http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png
Thanks,
Sven Brauch
, should the
custom providers be added to the list, or replace it? I.e., if I have custom
providers listed, should the default ones still be displayed or not?
- Sven Brauch
On March 11, 2013, 11:34 p.m., Sven Brauch wrote:
>
> ---
elease of python 3.4, the fork
would disappear anyways. (backporting is not possible since the patch
involves binary incompatible changes)
Best regards,
Sven
2013/3/12 Todd :
> On Tue, Mar 12, 2013 at 10:57 AM, Pino Toscano wrote:
>>
>> Hi,
>>
>> Alle sabato 9 marzo 2013
x27;t have a working provider server... yet.
File Attachments
a screenshot of the dialog showing two providers, one of them loaded from the
XML file specified in .knsrc
http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png
Thanks,
Sven Brauch
ttachments
a screenshot of the dialog showing two providers, one of them loaded from the
XML file specified in .knsrc
http://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png
Thanks,
Sven Brauch
uation where this fork specifically would be a problem.
Best regards,
Sven
2013/3/9 Pino Toscano :
> Hi,
>
> Alle sabato 16 febbraio 2013, Sven Brauch ha scritto:
>> A while ago, I asked for a review of kdev-python, in order for it to
>> be moved from playground to extrage
of
merging my patch is "somewhere before the feature freeze for this
release", so it might take a while -- far too long to keep kdev-python
stuck in kdereview.
Cheers,
Sven
2013/2/16 Sven Brauch :
> Hello,
>
> A while ago, I asked for a review of kdev-python, in order
m the master branch. I would however prefer not to do
this.
Thanks and best regards,
Sven Brauch
__
[1] http://bugs.python.org/issue16795
d the python code will happen rarely (if
ever)).
Here's the thread:
http://mail.python.org/pipermail/python-dev/2012-December/123320.html
Greetings,
Sven
2012/12/26 Sven Brauch :
> 2012/12/26 Ben Cooksley :
>> I see in that bug report that this was supposed to be referred to a
&g
2012/12/26 Ben Cooksley :
> I see in that bug report that this was supposed to be referred to a
> Python development mailing list as a result of the objections of a
> single person in that bug. What was the result of that?
Hello!
Nothing, it just died. Here is the thread:
http://mail.python.org/p
2012/12/26 Sune Vuorela :
> On 2012-12-25, Sven Brauch wrote:
>> Also, I'm still not sure what exactly concerns you about security and
>> maintenance. Problems I see include increased build time, and
>> maintenance efforts for me personally in updating the fork, but none
2012/12/25 Pino Toscano :
> Hi,
>
> (please do not top-post, thanks.)
>
> Alle venerdì 21 dicembre 2012, Sven Brauch ha scritto:
>> the two-week review period for this project (kdev-python) has passed.
>> The only complaint raised was related to the python fork in
Hi,
since there were no further questions or complaints, I will consider
kdev-python to have passed the review process now. Thanks!
Greetings,
Sven
2012/12/21 Sven Brauch :
> Hello,
>
> the two-week review period for this project (kdev-python) has passed.
> The only complaint raised
Hello,
the two-week review period for this project (kdev-python) has passed.
The only complaint raised was related to the python fork in the
repository. Was the necessarity of this sufficiently explained by my
follow-up email, or does anyone think this issue needs further
discussion?
Best regards
Hi!
Yeah, basic python3 support is there (syntax works) but not all the
features are handled correctly, e.g. nonlocal is not implemented yet
etc.
As milian already said, for 1.5 there will probably be two versions, a
python 2 and a python 3 one. Most of the development from now on will
happen for
are. Other fixes
are not relevant, since none of the runtime stuff is actually being
used by kdev-python (just the parser).
Greetings,
Sven
2012/12/6 Pino Toscano :
> Alle giovedì 6 dicembre 2012, Sven Brauch ha scritto:
>> If you find any issues, please tell me so I can fix them as qui
Hi!
For quite exactly two years I have been working on integrating the
Python scripting language into KDevelop. Recently this project, called
kdev-python, has seen its first stable release (called 1.4 in order to
match kdevplatform version numbers). The release seems to be
successful so far, no cr
68 matches
Mail list logo
