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
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
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
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
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
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
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,
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.
>
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 up
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
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
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
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
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 hughsi...@gmail.com 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
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 where
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
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
On Saturday 02 November 2013 19:48:01 Richard Hughes wrote:
On 2 November 2013 19:33, Albert Astals Cid aa...@kde.org 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
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
/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
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
://git.reviewboard.kde.org/r/113175/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
/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
/113175/diff/
Testing
---
Clicking files opens them in the default application, as it should.
Thanks,
Sven Brauch
e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---
On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
---
This is an automatically generated e-mail
:
http://git.reviewboard.kde.org/r/113175/#review41400
---
On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
---
This is an automatically generated e-mail. To reply, visit:
http
:
Honestly, to most people the internal viewer just looks broken, like an
incomplete stepchild of the real viewer application.
Can we please at least make the default to open the application, not the
crippled viewer?
Sven Brauch wrote:
I feel like Sebastian does and I have watched
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 you
On Wednesday 21 August 2013 23:23:35 David Faure wrote:
You could listen to the KDirNotify signal leftDirectory(url).
Awesome, thanks.
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)
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.
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:
---
This is an automatically generated e-mail. To reply, visit:
http
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 detected as
application-x-compressed-tar where
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 annemarie.mahf...@free.fr:
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++
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
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
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 aa...@kde.org:
El Dimecres, 3 d'abril de 2013, a les 10:53:32, Sven Brauch va escriure:
Hi list,
kdev
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
---
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., Sven Brauch wrote
/uploaddialog_p.h 1bb0af4
Diff: http://git.reviewboard.kde.org/r/109568/diff/
Testing
---
Thanks,
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.org/r/109568/
---
(Updated
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.org/r/109568
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
/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
on this, 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
://git.reviewboard.kde.org/media/uploaded/files/2013/03/11/newdialog1.png
Thanks,
Sven Brauch
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
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 toddr...@gmail.com:
On Tue, Mar 12, 2013 at 10:57 AM, Pino Toscano p...@kde.org wrote:
Hi,
Alle sabato 9 marzo 2013, Sven Brauch ha
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
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 svenbra...@googlemail.com:
Hello,
A while ago, I asked for a review of kdev-python, in order for it to
be moved from
the master branch. I would however prefer not to do
this.
Thanks and best regards,
Sven Brauch
__
[1] http://bugs.python.org/issue16795
and 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 svenbra...@googlemail.com:
2012/12/26 Ben Cooksley bcooks...@kde.org:
I see in that bug report that this was supposed
2012/12/25 Pino Toscano p...@kde.org:
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 the
repository
2012/12/26 Ben Cooksley bcooks...@kde.org:
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:
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 svenbra...@googlemail.com:
Hello,
the two-week review period for this project (kdev-python) has passed.
The only
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
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
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
62 matches
Mail list logo
