sometimes gets pretty big (just look at your own :) ). Which should not be a
problem if there is a simple way to stop qt forwarding those messages to
journalctl and get stuff back to .xsession-errors. Or there is a good
documented alternative way using journalctl features reaching similar results.
>
>
> Wouldn't that break KDElibs4 applications talking to kglobalacceld from KF5?
>
> - Martin Gräßlin
>
Yes it would. There can be only one kglobalaccel. If its from kde4 or kde4
shouldn't matter so it HAS to keep dbus compatibility.
On Friday, July 19, 2013 12:21:21 AM David Faure wrote:
> After more live discussion with Sebas and Marco plus Aaron over a video
> chat, we came up with the following setup for the workspace repos (*) :
>
> - the development branch for their next feature release (based on Qt5/KF5)
> will be "mast
On Friday, July 12, 2013 05:52:02 PM Aaron J. Seigo wrote:
> On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote:
> > Because of that it should be announced. BIG TIME. I am not hopeful because
>
> agreed. so what i’d like to see is a definitive listing of all the places
>
thanks!
>
> If that's the concern, we can certainly run such a script on one of the
> build machines, and it probably only needs someone puppy-eyeing a sysadmin
> to install it.
>
> Cheers,
Why not make a job on the jenkins/hudson machine(s)? They can be parametrized
(you give the
labels) or the relevant ones are added and run regularly. Would perhaps
increase the visibility of
those machines a bit.
--
Michael Jansen
http://michael-jansen.biz
ld be announced. BIG TIME. I am not hopeful because this
is the one
area we fail to get consistent all the time. Announcing our version control
strategy, changes and
anything related. I know because i am subscribed to all relevant mailing lists
and still fail to catch
many moves and changes. Only when stuff fails to compile i notice.
Mike
--
Michael Jansen
http://michael-jansen.biz
On Friday, May 03, 2013 02:39:31 PM Aaron J. Seigo wrote:
> hopefully you can put it in a repository that can be used by kdelibs which
would both get around the 4.x kdelibs freeze *and* prepare it for frameworks.
Just for clarification because i think i misunderstand something. The proposed
W
> Right, hence Volker's question about use cases. If people see a need to
> clear the cache then that needs to be implemented in some user facing tool.
> While destroying a setup will obviously also get rid of data, it will
> unavoidably also get rid of all data.
I usually kill all of kmail and ak
it in its current form.
Unless you are willing to go all the way which you only should do after finding
out what the frameworks branchs does to kaction. So you effort is not thrown
away in the near / middle future.
Mike
- Michael Jansen
On May 9, 2012, 6:21 p.m., Mark Gaiser wrote
list.
>
> -Allen
>
>
> ___
> KDE PIM mailing list kde-...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
--
Michael Jansen
http://michael-jansen.biz
On Tuesday, May 01, 2012 06:05:01 PM Mark Gaiser wrote:
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104801/
On April 30th, 2012, 10:19 p.m., David Faure wrote:
I am in favour of the idea, since I was hit by this limitation in the past,
too.
H
er bug or some ugly not really working
workarounds.
- Michael Jansen
On April 30, 2012, 3:41 p.m., Mark Gaiser wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
&g
ill sit in obscurity like before.
Because i won't follow you. And i guess some others won't either.
My 2 cent.
--
Michael Jansen
http://michael-jansen.biz
side.
Jenkins as far is i know only presents the results of one build. But i know it
can congregate the test results of more than one build. At least it can for
java. But i am not sure it can do it for builds running on different jenkins
instances.
CDash can. So each jenkins build could run the test and give them to cdash.
Best of both worlds.
Mike
--
Michael Jansen
http://michael-jansen.biz
and Paste problem. I apologize.
--
Michael Jansen
http://michael-jansen.biz
e some times in
between. Running nearly master of everything qt upwards.
--
Michael Jansen
http://michael-jansen.biz
On Thursday, January 05, 2012 12:17:33 AM Albert Astals Cid wrote:
> El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure:
> > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote:
> > > El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va
>
> escriure:
>
a blog post about
> > how doxygen sucks because it doesn't support QML. Then maybe Dimitry will
> > add it.
>
> What about adding qdoc support to doxygen?
If you mean writing documentation in the qt style and generating documentation
out of it then doxygen already supports that.
It is just the qml part that is not working (magically). But nothing prevents
you from having doxygen parse qml files and document everything in the
comments manually. But since i have no clue of qml i don't know if it is maps
to classes and methods.
@class Classname
@inherits OtherClase
...
Mike
>
> -Todd
--
Michael Jansen
http://michael-jansen.biz
On Friday, August 26, 2011 03:14:26 PM Stephen Kelly wrote:
> Aaron J. Seigo wrote:
> > On Friday, August 26, 2011 13:50:51 Michael Jansen wrote:
> >> That reminds me of my futile attempts to convince you guys of the need
> >> for a daily "is everything merged c
ts get in eventually or
> before it becomes hard to merge.
That reminds me of my futile attempts to convince you guys of the need for a
daily "is everything merged check" that sends its results (if stuff to merge
is open) to kde-core-develop list.
Somehow people thought it was not necessary.
Sigh
Mike
--
Michael Jansen
http://michael-jansen.biz
states if you plan to merge only once
or seldom. And rebasing is no alternative either because of the coordination
effort involved. At least my opinion.
Mike
--
Michael Jansen
http://michael-jansen.biz
> > > Also check the graphicssystem, "export QT_GRAPHICSSYSTEM raster" or
> > > "native", rather not "opengl"
> >
> > Will try that.
>
> So i understand compositing had no impact on this (the issue remained
> after disabling it)
Without compositing it worked normally. The second i pressed alt+s
On Sunday 31 July 2011 14:33:11 Thomas Lübking wrote:
> Am Sun, 31 Jul 2011 13:49:44 +0200
>
> schrieb Michael Jansen :
> > Failsafe did not change anything. Same result.
> >
> > I btw. suspect compositing too. How can i make sure compositing is
> > disabled b
On Sunday 31 July 2011 13:32:49 Martin Gräßlin wrote:
> On Sunday 31 July 2011 12:58:05 Michael Jansen wrote:
> > Hi @all
> >
> > I am currently trying to setup a compiled from sources master on opensuse
> > in a vm. I first tried kvm and then virtualbox.
> >
Hi @all
I am currently trying to setup a compiled from sources master on opensuse in a
vm. I first tried kvm and then virtualbox.
In both cases i got the same problem. The vms work as expected with the
opensuse 11.4 provided kde 4.6 (a bit sluggish but they work) and with any
other DE.
The mi
Hi
If i open the window menu (alt+f3) with the mouse the window shows up in the
top left corner of my screen. The reason is that the following code from
workspace/kwin/libkdecorations/kcommondecoration.cpp line 706
QRect menuRect = m_button[MenuButton]->rect();
QPoint menutop = m_button[Men
On Sunday 24 July 2011 20:27:58 Martin Gräßlin wrote:
> On Sunday 24 July 2011 14:12:21 Aurélien Gâteau wrote:
> > If there is no need for KDE System Settings on a Gnome desktop, then
> > adding a OnlyShowIn=KDE; key to the desktop file would be appropriate.
> > If on the other hand there is a need
On Thursday 14 July 2011 10:49:50 Ian Wadham wrote:
> On 14/07/2011, at 5:16 AM, Alexander Neundorf wrote:
> > What do you think of this ?
> > More wishes ?
> > Should it do it in a different way ?
>
> Very nice. I especially like the PURPOSE concept.
>
> As we discussed before, in connection wi
On Wednesday 29 June 2011 23:13:14 Simon Persson wrote:
> On Tuesday 07 June 2011 16.10.55 Aaron J. Seigo wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://git.reviewboard.kde.org/r/101515/#review3736
>
ed June 7, 2011, 7:21 a.m.)
>
>
> Review request for kdelibs and Michael Jansen.
>
>
> Summary
> ---
>
> Make this beautiful piece of code even more beautiful! The proper fix would
> be to add platform-specific functions to check if shift changes the symbol
wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101523/
> ---
>
> (Updated June 6, 2011, 11:24 a.m.)
>
>
> Review request for KDE Runtime
.kde.org/r/101520/
> ---
>
> (Updated June 6, 2011, 11:02 a.m.)
>
>
> Review request for KDE Runtime and Michael Jansen.
>
>
> Summary
> ---
>
> Second patch to fix this bug, depends on patch in review request 101515.
>
> KK
On Wednesday 06 April 2011 20:57:02 Alberto Mattea wrote:
> In data mercoledì 6 aprile 2011 20:43:40, Michael Jansen ha scritto:
> > > > You might also want to consider using KDE's
> > > > macro_optional_find_package() together with macro_log_feature(),
>
> > You might also want to consider using KDE's
> > macro_optional_find_package() together with macro_log_feature(), so you
> > show a list of all the dependencies which have or have not been found
> > instead of failing at the first one.
> >
> > I remember some discussions before about build-tim
Noone interested here? If noone speaks up i will just make the change assuming
noone cares.
Mike
On Sunday 06 March 2011 01:47:54 Michael Jansen wrote:
> On Friday 04 March 2011 20:49:08 Alex Merry wrote:
> > kdegraphics has now moved to git, with the exception of Okular and
>
On Friday 04 March 2011 20:49:08 Alex Merry wrote:
> kdegraphics has now moved to git, with the exception of Okular and
> mobipocket.
libkexiv2 still considers exiv2 a optional dependency even if the new
standalone project does not provide any other functionality.
In my case (exiv2 to old) it co
> The complicated nature of the feature is the reason for it, but the point I
> was trying to make was that each of the noisy aspects should be discouraged
> by discouraging merging and encuraging rebasing instead in the documented
> workflows.
A point where i btw. disagree. But i am not willing
> mjansen might just have been following a 'never rebase public branches'
> philosphy, but that really doesn't work for me. It was a complicated feature
> requiring lots of refactoring.
Hehe ... as the one doing the code i would say it was more like
mjansen stumbled through unchartered terr
On Saturday 05 February 2011 17:51:16 Mark wrote:
> Hi,
>
> let me first point you to this image (kde 4.6.0) :
> http://img89.imageshack.us/img89/5398/rightmousebuttondesktop.png
>
> Oke, first one shortcut in that image.
> I consider myself a experienced computer user in both windows and linux b
On Wednesday 02 February 2011 18:26:35 Alexander Neundorf wrote:
> On Wednesday 02 February 2011, Michael Pyne wrote:
> ...
>
> > e.g. worrying about environment variables like PKG_CONFIG_PATH is no
> > idle
> > claim (kdesrc-build sets that as well), along with PATH in order to pick
> > up the ri
> I guess this is not really the point of your discussion, but a rather
> a bad example you used...
Really? I meant it as an example that without compiling kwebkitpart before
kdebase you didn't get support for it in konqueror. Which you acknowledge if i
read your mail correctly happened at a t
> If you find the place let me know.
No ... only if i am unable to fix it myself :)) .
> > > Do you need that for running ?
> > > For building it's not necessary. Use CMAKE_PREFIX_PATH.
> >
> > I always thought that PATH controls which qt version is selected if you
> > have more than one (First
> > So want Aaaron and me to miss out on kwebkit and scripting, and
> > policykit
> > and rekonq and ... konsole? How do you suppose to use your system
> > without
> > konsole.
>
> Yes, with git this has become more stuff.
build-tool is able to compile more than 100 Modules. And run the stuff.
> a. nope. kwebkitpart only depends on kdelibs! There are no
> requirements besides that. The previous requirement that you must
> build kwebkitpart before you compiled the konq-plugins, which have now
> been moved to kdebase, is now longer valid because of the addition of
> several Extentsion
On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote:
> On Tuesday 01 February 2011, Michael Jansen wrote:
> > On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote:
> > > On Monday 31 January 2011, Aaron J. Seigo wrote:
> > > > On Sunday, Januar
On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote:
> On Monday 31 January 2011, Aaron J. Seigo wrote:
> > On Sunday, January 30, 2011, Michael Pyne wrote:
> > > Like I said, "xml-support" branch on kdesrc-build git. If you want
> > > to
> > > give
> >
> > _very_ cool. will the good new
> it could work out great, it could be a disaster, it could be a lot of work
> for a little gain ... we just can't tell right now because it's nothing
> more than a vague idea.
>
> you really can't plan the future of core assets like that.
But preparing our our assets in a way that would make id
On Sunday 31 October 2010 12:33:22 Mark Kretschmann wrote:
> Hey all,
>
> after reading the whole thread that started with Chani's mail ("why
> kdelibs?"), I think the noise level has become a bit too much there.
> Cornelius had proposed this rather daring idea:
>
> http://lists.kde.org/?l=kde-co
48 matches
Mail list logo
