@elvisangelaccio i want to go ahead with this patch.

If someone steal events it's not problem of the patch, similar patch as D15612 should be applied for that view.

Use parent in createInstance

As i mention before, that's not a patch issues.

@ngraham, you can test it.

ping

Can you push it, i've some problems - the change is small, thank you.

Remove locking inside media object
Still has a deadlock inside gstreamer

Thread 1 "dragon" received signal SIGINT, Interrupt.
0x00007ffff11f541c in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff11f541c in __lll_lock_wait () at /lib/libpthread.so.0
#1  0x00007ffff11eeb96 in pthread_mutex_lock () at /lib/libpthread.so.0
#2  0x00007fffc88d8001 in  () at /usr/lib/gstreamer-1.0/libgstplayback.so
#3  0x00007fffdb6f2d07 in gst_element_query () at /usr/lib/libgstreamer-1.0.so.0
#4  0x00007fffdb74a6ea in gst_element_query_position () at /usr/lib/libgstreamer-1.0.so.0
#5  0x00007fffdba41034 in Phonon::Gstreamer::Pipeline::position() const () at /usr/lib/qt5/plugins/phonon4qt5_backend/phonon_gstreamer.so
#6  0x00007fffdba32b5e in Phonon::Gstreamer::MediaObject::emitTick() [clone .part.17] () at /usr/lib/qt5/plugins/phonon4qt5_backend/phonon_gstreamer.so
#7  0x00007fffdba35c4f in Phonon::Gstreamer::MediaObject::qt_static_metacall(QObject*, QMetaObject::C--Type <RET> for more, q to quit, c to continue with all, int, void**) () at /usr/lib/qt5/plugins/phonon4qt5_backend/phonon_gstreamer.so
#8  0x00007ffff3b37e22 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5
#9  0x00007ffff4589e3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#10 0x00007ffff4590f5f in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#11 0x00007ffff3b098f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#12 0x00007ffff3b0c295 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt5Core.so.5
#13 0x00007ffff3b61313 in  () at /usr/lib/libQt5Core.so.5
#14 0x00007fffec5002f7 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#15 0x00007fffec500508 in  () at /usr/lib/libglib-2.0.so.0
#16 0x00007fffec50058c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#17 0x00007ffff3b609af in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)() at /usr/lib/libQt5Core.so.5
#18 0x00007fffe5f1c3b1 in  () at /usr/lib/qt5/plugins/platforms/../../../libQt5XcbQpa.so.5
#19 0x00007ffff3b081da in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#20 0x00007ffff3b10cd0 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#21 0x0000000000438514 in main ()

In facts that's 2 crashes, first one in ascent, second one misfit.

@danders you can commandeer this revision to update diff.

Yep, it's look like same approach to mine, did you try mine or it's not correct in all cases?

@broulik, @thsurrel any other ideas or to commit it?

Still has a problem, after aboutToFinish is emitted and queue is not empty, after setting new source paint of window freeze.

@danders that was one of my previous approach. Let @boemann tolds us which is correct one.

I saw another issue, when we waiting new source (MediaObject::setNextSource) it set m_pipeline to new source but since we have only one pipeline gstreamer starts notify us for states of new source which is paused state, that reflect to emit signal of state changed to paused. I don't know how pipeline more that one source ever works on gstreamer. I'll update patch.

Yeah, i know that, but i have a reason to do it - no cost :) Basically code base is same, so limitation is virtual, about me.

Adding context to diff

https://cgit.kde.org/dragon.git/commit/?h=Applications/18.12&id=addaf47d1af218a46777f740bdc9d579a16bdf1f

Also fix max comic strips limit

It crashes, you can see backtrace, start long-running analysis and close Kate before it finish.

I prefer to not having config on this. We can limit them to 4. I test with big projects using boost and Qt, ~2000 files, RAM is not an issue (~25 MB on process) but performance. By one job project is really not ending, takes more than hour, by increasing jobs things became more reliable.

Any objections on this?

There's no problem at all
http://doc.qt.io/qt-5/qprocess.html#dtor.QProcess

I'll commit it as soon you accept.

Use qAsConst

Isn't there. https://phabricator.kde.org/source/powerdevil/browse/master/daemon/backends/upower/xrandrbrightness.cpp$160 You can investigate on what backend it's used for you and it may set value only one output not to all.

To 18.12 ?

Ok, let not make whitespace commit. @ognarb just be more precise next time.

Ping

Kernel regression for sure.

@thsurrel try this patch, if it not help disable dim display from power saving configuration, is that help?

Ping

Ping

That's change in 1.14 i think, so right after state goes to ready on stream gstreamer triggers signal sync-message::buffering with percentage 0 that's cb_buffering on other hand we change immediately state to paused in, so gstreamer starts buffering again and when goes to 100% we end up with playing state.

I will push it in few days, since no activity.

+1

I have noticed it too, please to 18.12.

Ping

Ping

Yep, it's Qt bug.

It looks like the problem is in dimming.

So i like second one, it can still be fixed to 10K+ because it does not matter above.

In D17152#365975, @ndavis wrote:

Why not abbreviate the number? Instead of using "9,999+" for 11000, use "11K".

To commit it @mart @broulik ?

It's mostly one per day or accept configuration.