[kmail2] [Bug 317803] Kmail2 renders colors based on the user system colors rather than the default colors browsers use.

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=317803

Mark  changed:

   What|Removed |Added

 CC||mw471...@gmail.com

--- Comment #5 from Mark  ---
I too would like to see this addressed. I appreciate all the hard work that has
gone into KMail over the years, but it seems in this respect it's been
superannuated somewhat by trends in desktop themes. 

Running a dark theme makes ~80% of the HTML emails I receive unreadable in
KMail, which is a shame as I otherwise love it and Kontact alike. 

In it's simplest form, it could be a checkbox called "Force white background
and black text for HTML email."

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 370936] New: Segfault when copying between two hard drives

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370936

Bug ID: 370936
   Summary: Segfault when copying between two hard drives
   Product: dolphin
   Version: 16.08.2
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: magpie...@gmx.com

Application: dolphin (16.08.2)
 (Compiled from sources)
Qt Version: 5.6.2
Frameworks Version: 5.27.0
Operating System: Linux 4.4.24-Generic x86_64
Distribution: "Linux From Scratch"

-- Information about the crash:
- What I was doing when the application crashed:
Copying user files from old system on sdb to new system on sda opened in two
tabs.

The crash can be reproduced every time.

-- Backtrace:
Application: Dolphin (dolphin), signal: Segmentation fault
[KCrash Handler]
#6  0x7f5966d5e304 in free () at /lib/libc.so.6
#7  0x7f5967bb67b4 in QObjectPrivate::Connection::~Connection() () at
/opt/qt5/lib/libQt5Core.so.5
#8  0x7f5967bba3ac in QObjectPrivate::cleanConnectionLists() () at
/opt/qt5/lib/libQt5Core.so.5
#9  0x7f5967bbb1ce in QObjectPrivate::addConnection(int,
QObjectPrivate::Connection*) () at /opt/qt5/lib/libQt5Core.so.5
#10 0x7f5967bbb484 in  () at /opt/qt5/lib/libQt5Core.so.5
#11 0x7f5967bbea9a in QObject::connect(QObject const*, char const*, QObject
const*, char const*, Qt::ConnectionType) () at /opt/qt5/lib/libQt5Core.so.5
#12 0x7f596d5250c0 in  () at /opt/kf5/lib/libKF5KIOCore.so.5
#13 0x7f596d54310a in  () at /opt/kf5/lib/libKF5KIOCore.so.5
#14 0x7f5967bb8879 in QMetaObject::activate(QObject*, int, int, void**) ()
at /opt/qt5/lib/libQt5Core.so.5
#15 0x7f5967bc4df8 in QTimer::timerEvent(QTimerEvent*) () at
/opt/qt5/lib/libQt5Core.so.5
#16 0x7f5967bb92cb in QObject::event(QEvent*) () at
/opt/qt5/lib/libQt5Core.so.5
#17 0x7f5968d6214c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /opt/qt5/lib/libQt5Widgets.so.5
#18 0x7f5968d6725f in QApplication::notify(QObject*, QEvent*) () at
/opt/qt5/lib/libQt5Widgets.so.5
#19 0x7f5967b8c9b0 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /opt/qt5/lib/libQt5Core.so.5
#20 0x7f5967bdf71e in QTimerInfoList::activateTimers() () at
/opt/qt5/lib/libQt5Core.so.5
#21 0x7f5967bdfc31 in  () at /opt/qt5/lib/libQt5Core.so.5
#22 0x7f5961499d77 in g_main_context_dispatch () at
/usr/lib/libglib-2.0.so.0
#23 0x7f5961499fa8 in  () at /usr/lib/libglib-2.0.so.0
#24 0x7f596149a04c in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#25 0x7f5967be076f in
QEventDispatcherGlib::processEvents(QFlags) ()
at /opt/qt5/lib/libQt5Core.so.5
#26 0x7f5967b8ac5a in
QEventLoop::exec(QFlags) () at
/opt/qt5/lib/libQt5Core.so.5
#27 0x7f5967b92f5d in QCoreApplication::exec() () at
/opt/qt5/lib/libQt5Core.so.5
#28 0x7f596f196347 in kdemain () at /opt/kf5/lib/libkdeinit5_dolphin.so
#29 0x7f5966d03291 in __libc_start_main () at /lib/libc.so.6
#30 0x004009aa in _start ()

Possible duplicates by query: bug 366639, bug 364038.

Reported using DrKonqi

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 369664] Crash after removing desktop entry

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369664

--- Comment #3 from Mark  ---
After removing the application it still appeared on the menu so I 
started it, expecting it would force a menu update.


On 04/10/16 00:15, Marco Martin via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=369664
>
> --- Comment #1 from Marco Martin  ---
> from the bt, you started an app (probably linked to the very same desktop 
> file)
> what was it? favorites, all apps, most used.. ?
>

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 369664] New: Crash after removing desktop entry

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369664

Bug ID: 369664
   Summary: Crash after removing desktop entry
   Product: plasmashell
   Version: 5.7.95
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: magpie...@gmx.com
CC: bhus...@gmail.com, plasma-b...@kde.org

Application: plasmashell (5.7.95)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.26.0
Operating System: Linux 4.4.14 x86_64
Distribution: "Linux From Scratch"

-- Information about the crash:
- What I was doing when the application crashed:

Deleted a .desktop entry from /usr/share/applications. Went to use Kickoff then
Plasma crashed. Entry gone, unable to repeat.

-- Backtrace:
Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f6e7c7c4800 (LWP 3591))]

Thread 20 (Thread 0x7f6d7c9cd700 (LWP 24630)):
#0  0x7f6e738073a8 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x7f6e71de8e94 in  () at /usr/lib/libGL.so.1
#2  0x7f6e6a756522 in  () at /usr/lib/libnvidia-glcore.so.340.96
#3  0x7f6e71de8da4 in  () at /usr/lib/libGL.so.1
#4  0x7f6e738013e4 in start_thread (arg=0x7f6d7c9cd700) at
pthread_create.c:333
#5  0x7f6e74494cfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 19 (Thread 0x7f6d65dea700 (LWP 24629)):
#0  0x7f6e73806fff in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f6e75083a5a in QWaitCondition::wait(QMutex*, unsigned long) () at
/opt/qt5/lib/libQt5Core.so.5
#2  0x7f6e79ea013d in  () at /opt/qt5/lib/libQt5Quick.so.5
#3  0x7f6e79ea09b5 in  () at /opt/qt5/lib/libQt5Quick.so.5
#4  0x7f6e7508348d in  () at /opt/qt5/lib/libQt5Core.so.5
#5  0x7f6e738013e4 in start_thread (arg=0x7f6d65dea700) at
pthread_create.c:333
#6  0x7f6e74494cfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 18 (Thread 0x7f6d8dc24700 (LWP 3950)):
#0  0x7f6e738073a8 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x7f6e71de8e94 in  () at /usr/lib/libGL.so.1
#2  0x7f6e6a756522 in  () at /usr/lib/libnvidia-glcore.so.340.96
#3  0x7f6e71de8da4 in  () at /usr/lib/libGL.so.1
#4  0x7f6e738013e4 in start_thread (arg=0x7f6d8dc24700) at
pthread_create.c:333
#5  0x7f6e74494cfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 17 (Thread 0x7f6d8e425700 (LWP 3949)):
#0  0x7f6e73806fff in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f6e75083a5a in QWaitCondition::wait(QMutex*, unsigned long) () at
/opt/qt5/lib/libQt5Core.so.5
#2  0x7f6e79ea013d in  () at /opt/qt5/lib/libQt5Quick.so.5
#3  0x7f6e79ea09b5 in  () at /opt/qt5/lib/libQt5Quick.so.5
#4  0x7f6e7508348d in  () at /opt/qt5/lib/libQt5Core.so.5
#5  0x7f6e738013e4 in start_thread (arg=0x7f6d8e425700) at
pthread_create.c:333
#6  0x7f6e74494cfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 16 (Thread 0x7f6d8f5fd700 (LWP 3782)):
#0  0x7f6e738073a8 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x7f6e71de8e94 in  () at /usr/lib/libGL.so.1
#2  0x7f6e6a756522 in  () at /usr/lib/libnvidia-glcore.so.340.96
#3  0x7f6e71de8da4 in  () at /usr/lib/libGL.so.1
#4  0x7f6e738013e4 in start_thread (arg=0x7f6d8f5fd700) at
pthread_create.c:333
#5  0x7f6e74494cfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 15 (Thread 0x7f6da1166700 (LWP 3781)):
#0  0x7f6e73806fff in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f6e75083a5a in QWaitCondition::wait(QMutex*, unsigned long) () at
/opt/qt5/lib/libQt5Core.so.5
#2  0x7f6e79ea013d in  () at /opt/qt5/lib/libQt5Quick.so.5
#3  0x7f6e79ea09b5 in  () at /opt/qt5/lib/libQt5Quick.so.5
#4  0x7f6e7508348d in  () at /opt/qt5/lib/libQt5Core.so.5
#5  0x7f6e738013e4 in start_thread (arg=0x7f6da1166700) at
pthread_create.c:333
#6  0x7f6e74494cfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 14 (Thread 0x7f6d8fffe700 (LWP 3682)):
#0  0x7f6e738073a8 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x7f6e71de8e94 in  () at /usr/lib/libGL.so.1
#2  0x7f6e6a756522 in  () at /usr/lib/libnvidia-glcore.so.340.96
#3  0x7f6e71de8da4 in  () at /usr/lib/libGL.so.1
#4  0x7f6e738013e4 in start_thread (arg=0x7f6d8fffe700) at

[ktorrent] [Bug 366627] New: Columns settings aren't retained

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366627

Bug ID: 366627
   Summary: Columns settings aren't retained
   Product: ktorrent
   Version: 5.0
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: joris.guis...@gmail.com
  Reporter: magpie...@gmx.com

Column settings reset each time KTorrent is launched. Magnet downloader seems
inoperative. Oh, and pleased to see development has resumed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 366603] New: First alt-tab press not handled

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366603

Bug ID: 366603
   Summary: First alt-tab press not handled
   Product: kwin
   Version: 5.7.3
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: effects-tabbox
  Assignee: kwin-bugs-n...@kde.org
  Reporter: mark...@gmail.com

I've notices this for a while now, i think it's since the shared QQmlEngine.
But i was never quite sure if i just mis-pressed alt-tab or if the first one
really didn't get handled. Now i sat down and really test this. It's really not
being handled.

Reproducible: Always

Steps to Reproduce:
1. Restart your Plasma 5 environment. Just killing and restarting plasmashell
does not make this issue visible. Better start with a freshly started
environment form the login manager.
2. Open 2 applications
3. Press alt+tab
4. Nothing happens
5. Press alt+tab again
6. now it works :)

Actual Results:  
Pressing alt+tab for the first time after logging in from the loginmanager (and
starting 2 apps afterwards) does nothing. Pressing alt+tab for the second time
works as expected. Any alt+tab presses afterwards works just fine. 

Expected Results:  
The first alt+tab press should also show the window switcher

I tested this on:
- Intel desktop with nvidia graphics
- intel laptop with intel graphics
- virtualbox environment

All show the very same issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 198175] Konsole should set blur region for the new kwin effect

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #78 from Mark  ---
(In reply to Thomas Lübking from comment #77)
> It's an X11 property - you can query it using XLib/xcb API.
> Adding a KWindowSystem getter sounds a bit off for technically only the
> WM/compositor should ever read it.
> 
> The discussion back then was to shovel this  to the GUI style (for it may
> also have wanted to impact this but since Qt5 doesn't support depth changes
> of existing windows, that point is now more or less void)
> 
> I'd suggest to go for a relaxed protocol (gentleman's agreement) on some
> dynamic Qt property on the widgets and a static KStyle helper to traverse
> all widgets in a window for the blur props, merge them into a region and set
> the X11 property via KWindowSystem
> 
> You'd then
> myWidget->setProperty("kwin_fx_blur", QRegion);
> KStyle::updateBlur(myWidget->window()); // schedules a run for the end of
> the event cycle

Hi Thomas,

Thank you for that information.

I was already getting a bit of a feeling like "oh boy, this is not on a simple
patch level anymore". And your explanation confirms that. 

I'm sorry, but this is not on a patch level anymore that i feel comfortable
with.
I would have been fine by touching Konsole code and perhaps a few other
framework libraries to get this implemented. But touching XLib/XCB is a
showstopper for me, that's where i drop out.

We're back to one of my earlier assessments for this issue. It's very difficult
to implement while the basic functionality is so easy to get.

Good thing is that every aspect of this issue and how to implement it is now
described in this bug report, hehe.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 198175] Konsole should set blur region for the new kwin effect

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #76 from Mark  ---
(In reply to Eike Hein from comment #75)
> > konsole shouldn't set the blur region if the parent app in which it lives 
> > sets the blur (Yakuake for instance).
> 
> No, I'm saying when TerminalDisplay sets the blur region, it needs to not
> replace the blur region but merge its intended blur region with whatever is
> already set. This is technically still problematic in the case where
> TerminalDisplay's blur region fully contains a blur region "write" by
> someone else that it might later unset when disabling blur in the profile,
> but that's an extreme edge case probably not worth worrying too much about -
> I don't know of any existing app where it would actually be a problem.

But there is a catch.. How do you get the blur region that might already be
set?
There is no function for that in KWindowSystem (which is used to set the
region).

If you can clarify this last thing with a possible way to implement it, then i
can go right ahead and make a nice patch :)
> 
> > That way, if it gets embedded it should still behave nicely when the parent 
> > sets the blur hint for the region it wants.
> 
> Then Dolphin needs it's own "Blur behind terminal" option - not really
> smart. It's nicer to place it in the Konsole profile options.
> 
> The algo is basically:
> 
> - catch relevant events for widget geometry change
> - get current blur region
> - map old widget geo to window
> - remove from blur region
> - map new widget geo to window
> - add to blur region
> - set blur region

Thank you for that elaborate explanation. That certainly makes it clear how you
want it to be implemented.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 198175] Konsole should set blur region for the new kwin effect

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #74 from Mark  ---
(In reply to Eike Hein from comment #73)
> If you're saying you only want blur support in Konsole: TerminalDisplay is
> private API, so it can have a setBlurSupported or whatever that only Konsole
> calls but not the KPart. But that means no blur for e.g. Yakuake, which
> means many users won't be satisfied by the solution.

We're mixing things up here. That's probably because you know a lot more about
Konsole then I do :)

I want to implement this in a way that satisfies everyone.

You just told me that - for instance - konsole shouldn't set the blur region if
the parent app in which it lives sets the blur (Yakuake for instance).
Therefore i'm proposing an idea to only have the blur be set when the
application itself is Konsole, not embedded. That way, if it gets embedded it
should still behave nicely when the parent sets the blur hint for the region it
wants. If Konsole happens to be in that region, it would be blurred as well,
right?

I don't know how the internals work, but in my mind this "idea" should work and
allows other parties that embed it to blur whatever they want.

Please elaborate in detail if this doesn't work in principle for whatever
reason.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 198175] Konsole should set blur region for the new kwin effect

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #72 from Mark  ---
Isn't it far easier to allow the blur setting to be ticked if the application
is a main application and not set the blur hint if it isn't? Wouldn't that fix
all the cases? Or something like if the root window is the konsole main window.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 198175] Konsole should set blur region for the new kwin effect

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #69 from Mark  ---
(In reply to Eike Hein from comment #68)
> Option in the profie + TerminalDisplay needs to track its position inside
> its host window and merge its geometry with the blur region. Even then it's
> technically possible for it to screw up though.

Just curious.
Why is there a need for TerminalDisplay to track it's position inside the host
window and merge the geometry? (by merge i guess you mean
rectFromHost.united(rectFromTerminal) where both are of QRect or QRectF).

I obviously need to test that it works, but how would i test that? Can you give
me a clear usecase that will go wrong if i enable blurring that will be just
right if i add geometry tracking? That would help me a lot in implementing this
and getting it right the first time (oke, technically the second time since i
already made a patch for this the easy way a couple years back, hehe).

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 198175] Konsole should set blur region for the new kwin effect

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=198175

--- Comment #67 from Mark  ---
What is te consensus on this issue?
I would like to have it and want to make a patch for it whatever the consensus
is. Shall i go ahead and make it a checkbox in the "Edit color scheme" dialog
(under Appearance -> Edit)? I'm fine doing this *if* it isn't vetoed by someone
since that would just be wasting my time.

It's clear there is a case for this for some (me included) and for others to
specifically not have this and you now have me offering my help to implement
it.

By reading (parts of) this thread again, it looks like i need a consensus from
Martin Gräßlin and Eike Hein. Could you two decide where it needs to be
implemented, please? Once i have that, expect a patch for it within a few days
:)

Deal?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 364753] New: NetworkManager tries to connect to wired interface even though it's down

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364753

Bug ID: 364753
   Summary: NetworkManager tries to connect to wired interface
even though it's down
   Product: plasma-nm
   Version: master
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: applet
  Assignee: jgrul...@redhat.com
  Reporter: mark...@gmail.com
CC: lu...@kde.org

Hi,

I'm guessing the issue isn't in the QML part of the network manager applet. But
i don't know which part it would be then. Please assign this bug to the
appropriate part.

I've had this issue for years and i think i've submitted a bug report about it
before as well. But i cant find that one anymore so i'm reporting it again.
When you are one a wifi enabled device and you have a wifi connection, but no
wired connection then NetworkManager tries to connect to the wired connection
regardless. It only stops doing so when i deactivate the wired connection.

I find this weird, because my wired state is what i would expect. It's down,
according to /sys/class/net/enp2s0/operstate.

The net result is that NetworkManager tries to connect to a wired connection,
which it can't because it's down so you get two popups again. One indicating it
unavailable and one indicating the connection is deactivated. That last one is
wrong btw, the connection is not deactivated at all and a minute later it tries
again.. yay.

My "workaround" is disabling the wired connection, which stops the re
connection attempts. This obviously is not a "fix".

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 322219] Should not ask for wallet access when no password is used

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=322219

Mark  changed:

   What|Removed |Added

 CC||mark...@gmail.com

--- Comment #6 from Mark  ---
I have the exact same issue (on a WPA2 connection though), and i *really really
really* HATE it! I always have this issue and always have to spend hours
working through hoops to get my connection to work...

I disabled KWallet. I don't use it and i don't want to use it! I'm the only
user on the computer. I don't give a damn if the passwords are stored in plain
text.

So what do i have now. I have an extremely vague popup asking me (in the exact
words): "For accessing the wireless netword  you need to provide a
password below"

Can it be any more cryptic?
I tried my user password (not working).
I tried the root password (not working).
I tried the wifi password (not working).
Or even my kwallet password which is non existing...

WHICH PASSWORD!?!?!

Please, really... Make the dialog intuitive! I'm much faster off now by just
not using networkmanager for password protected connections then using it.

What i *guess* is happening is plasma-nm probably trying to out smart me (it
fails at that) and trying to ask for a password to unlock kwallet. Which it
won't be able to since that service is shut down.

Also, this just works in Gnome/Unity. Why do i have to go through hoops to get
it working in plasma? That really smells fishy to me.

I guess my only way to get this working at this moment is apparently accepting
the use of kwallet which will give me access to my wifi... I refuse to do that!

Please do not make kwallet mandatory!

-- 
You are receiving this mail because:
You are watching all bug changes.

[Touchpad-KCM] [Bug 362800] Touchpad setting "Disable taps and scrolling only" ignored

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362800

--- Comment #5 from Mark  ---
I apologize for double-posting in such quick succession but I wanted to report
that I replaced libinput with synaptics as you described and all is working as
expected again.  Thank you again for your assistance.  I suppose I'll keep an
eye on libinput's development and switch back again once these features are
supported.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Touchpad-KCM] [Bug 362800] Touchpad setting "Disable taps and scrolling only" ignored

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362800

--- Comment #4 from Mark  ---
Thanks for such a fast response Rajeesh.  This may not be the best place to
ask, but is libinput in its feature-incomplete state not a suitable replacement
for the synaptics driver at this time?  I haven't yet tried using the synaptics
driver to work around my problem, but I'll try it and post the results.  Thank
you again for your help.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Touchpad-KCM] [Bug 362800] Touchpad setting "Disable taps and scrolling only" ignored

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362800

--- Comment #2 from Mark  ---
Thank you for your response Rajeesh.  Here is the output you requested:

272 libinput Tapping Enabled
273 libinput Tapping Enabled Default
274 libinput Tapping Drag Lock Enabled
275 libinput Tapping Drag Lock Enabled Default

It seems I am in fact using libinput.  I suppose I can try and switch back to
using Synaptics as the driver to see if it works.  Let me know if there's
anything else you would like to provide.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Touchpad-KCM] [Bug 362800] New: Touchpad setting "Disable taps and scrolling only" ignored

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362800

Bug ID: 362800
   Summary: Touchpad setting "Disable taps and scrolling only"
ignored
   Product: Touchpad-KCM
   Version: 5.5.5
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: kcm
  Assignee: rajeeshknamb...@gmail.com
  Reporter: mark.fit...@hotmail.com

I have an HP Envy 17 which includes a no-button touchpad.  Using KDE System
Settings I can enable the touchpad setting "Disable touchpad when typing"
however the sub-setting "Disable taps and scrolling only" is not honored. 
Further, disabling the main setting "Disable touchpad when typing" is not
honored either, whether or not I log out and back in or reboot the system.

Reproducible: Always

Steps to Reproduce:
1. Open System Settings -> Input Devices -> Touchpad -> Enable/Disable Touchpad
2. Ensure "Disable touchpad when typing" and "Disable taps and scrolling only"
are enabled
3. Open Kate (text editor) and continually hold a key, such as 'w' while trying
to move the mouse cursor with the touchpad.

Actual Results:  
The mouse cursor does not move.  Releasing the 'w' key will allow mouse cursor
movement again using the touchpad.

Expected Results:  
The mouse cursor responds to movement requests even during keyboard key
presses.

I have both the xorg-x11-drv-synaptics and xorg-x11-drv-libinput installed on
my Fedora 23 x64 install.  I've already tried renaming the files
/usr/share/X11/xorg.conf.d/50-synaptics.conf and
/usr/share/X11/xorg.conf.d/90-libinput.conf as suggested in another bug report:
https://bugs.kde.org/show_bug.cgi?id=360943, but it didn't work.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-plasma] [Bug 349669] Tooltip jumps to top of screen after clicking on quick launch icon

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=349669

Mark  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Mark  ---
(In reply to Marco Martin from comment #7)
> is still happening on Plasma 5.6?

It seems to be working fine now. Thank you for taking care and closing this
issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 362568] The clip monitor is not showing any transitions or effects applied to it - plus two other things

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362568

--- Comment #2 from Mark  ---
Hi Jean

I feel so stupid, I didnt realise that there were two different clip 
viewing views. once I enabled the project monitor things behaved as 
expected. Apologies for the false bug report.

Cheers

Mark

On 02/05/16 18:42, Jean-Baptiste Mardelle via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=362568
>
> Jean-Baptiste Mardelle  changed:
>
> What|Removed |Added
> 
>   CC||j...@kdenlive.org
>
> --- Comment #1 from Jean-Baptiste Mardelle  ---
> Well, there are 2 monitors in Kdenlive.
> - The "Clip Monitor" displays the clip from the project bin
> - The "Project Monitor" displayse the timeline content.
>
> Monitors can be shown/hidden from the view menu.
> Does enabling "Project Monitor" solve your problem ?
>

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 362568] New: The clip monitor is not showing any transitions or effects applied to it - plus two other things

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362568

Bug ID: 362568
   Summary: The clip monitor is not showing any transitions or
effects applied to it - plus two other things
   Product: kdenlive
   Version: 16.04.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: grave
  Priority: NOR
 Component: Effects & Transitions
  Assignee: vpi...@kde.org
  Reporter: thinkingbeyondthesqu...@gmail.com

Any effect or transition made to the video isnt shown on the clip monitor.
Secondly clicking on the timeline to select frame position has no effect on the
clip monitor. And sometimes muting the video on the time line makes no
difference to the clip monitor either - it continues to show the same clip. If
i was to guess I would say it is looking at the clip in the Project Bin and not
the main video/timeline.

Hope this info helps improve kdenlive as atm it is unusable for me (and ive
used it alot over the years).

Cheers

Mark

Reproducible: Always

Steps to Reproduce:
1.import any video
2. drop video to timeline
3.apply any effect to it
4.hit play on clip monitor - effect is not shown (though does render if i
render the timeline)

Actual Results:  
the clip monitor is not showing applied effects

Expected Results:  
shown the applied effects/transitions

I installed the latest kdenlive software on the chance that the latest dev
version may have fixed the issue, (i was using the latest on Ubuntu 16.04 but
it too was failing - from memory i think it was something like 15.5.4 -
whatever is the current state of kdenlive in ubuntu 16.04 repo)

-- 
You are receiving this mail because:
You are watching all bug changes.

[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359572

--- Comment #5 from Mark  ---
(In reply to Allen Winter from comment #4)
> recently I added code like this to a project.
> Might be of use to you.
> 
>   string(TOUPPER ${CMAKE_BUILD_TYPE} UPPER_BUILD_TYPE)
>   if(${UPPER_BUILD_TYPE} MATCHES "^DEBUG")
> set_target_properties(your_library PROPERTIES DEBUG_POSTFIX "d")
>   endif()

I don't think it's that easy.

That would probably work and create a d-suffixed library, however using "QT +=
KArchive" would probably still try to load the non d-suffixed library. Unless
set_target_properties also handles the qmake stuff?

Also, adding this manually is a workaround. This should be addressed in ECM so
that all build (on windows) get d-suffixed debug builds.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 358719] fcitx creates blank unusable xembed icon in systray

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358719

--- Comment #9 from Mark  ---
this actually appears to be fixed for me in plasma 5.5 on openSUSE leap 42.1
Thanks for the work.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 352055] plasma-pa plasmoid not shown in systemtray after startup

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352055

--- Comment #90 from Mark  ---
yes, things seem to be working well for me also with the update to plasma 5.5.5
on openSUSE Leap 42.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 352055] plasma-pa plasmoid not shown in systemtray after startup

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352055

--- Comment #83 from Mark  ---
(In reply to Raghavendra kamath from comment #81)
> Dropbox icon is missing too.

there is a bug in Dropbox 3.14.5 (and newer) that prevents the icon loading.
Nothing to do with Plasma.
You should be able to get the icon back with this command

dropbox stop && dbus-launch dropbox start

-- 
You are receiving this mail because:
You are watching all bug changes.

[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359572

--- Comment #2 from Mark  ---
 > Your line "Lastly" surprises me --- if it points to the actual name of the
> DLL, then it should work, with the current naming, no?

That works as long as the dll name is KF5Archive.dll (for debug and release, no
d suffix for the debug library) AND when using QT += KArchive.

When renaming the debug DLL to have the d suffix that doesn't work anymore. At
least not with QT += KArchive (it doesn't know KF5Archived.dll?). That only
works if you manually add the include path and manually add the appropriate
library for debug and release (LIBS += -l...), which kinda makes using "QT +=
KArchive" useless since it's being done manually in this case. I can easily
work around this in the project where KArchive is used, but I was kinda
expecting the dll's to work the same as Qt's own dll's (which do have a d
suffix for debug) and have the QT += foo magically use the appropriate DLL
based on the build setting.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-karchive] [Bug 359572] New: Windows build, debug library is not d suffixed.

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359572

Bug ID: 359572
   Summary: Windows build, debug library is not d suffixed.
   Product: frameworks-karchive
   Version: unspecified
  Platform: Other
OS: other
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: fa...@kde.org
  Reporter: mark...@gmail.com
CC: kdelibs-b...@kde.org

Hi,

When compiling KArchive on windows (cmake for the configure step ...
-DCMAKE_BUILD_TYPE=debug ..., nmake for building) then you end up with
KF5Archive.dll, not KF5Archived.dll (note the "d").

Also, the file "qt_KArchive.pri" misses a "QT.KArchive.bins" line, it's where
the DLL is stored.

Lastly, when running a QMake project with QT += KArchive then at runtime it
will search for KF5Archive.dll instead of KF5Archived.dll.

Having the debug library to be "d" suffixed would be best since that allows one
to run the app in debug and release mode. Also, Qt does this as well for all
libraries so i guess KF5 (specifically tier 1 libraries) should follow that
example.

P.s. the version field here only goes as far as 5.1.0... I have 5.19.0 ;)

Best regards,
Mark

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 358719] fcitx creates blank unusable xembed icon in systray

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358719

--- Comment #2 from Mark  ---
would love to but unfortunately fcitx as of late 2015 has no bug reporting /
tracking system due to google-code shutting down their issue tracker.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 358719] New: fcitx creates blank unusable xembed icon in systray

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358719

Bug ID: 358719
   Summary: fcitx creates blank unusable xembed icon in systray
   Product: plasmashell
   Version: 5.5.4
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: XembedSNIProxy
  Assignee: plasma-b...@kde.org
  Reporter: mrkf...@yahoo.co.nz

prior to plasma 5.5.4 fcitx (ime) prevented xembed icons loading in system
tray.
This was fixed in plasma 5.5.4 and now fcitx and xembed icons can happily
coexist.
However, fcitx now creates a blank xembed icon in systray along with its usual
ime/keyboard icon.
The blank icon can be hidden in systray settings but on reboot the "hide"
setting resets to "auto" and the blank icon is visible again.

Reproducible: Always



Expected Results:  
a blank xembed icon should not be created in systray by fcitx as it serves no
practical purpose.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-pa] [Bug 352055] plasma-pa plasmoid not shown in systemtray after startup

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352055

--- Comment #56 from Mark  ---
Created attachment 96559
  --> https://bugs.kde.org/attachment.cgi?id=96559=edit
half an icon

so plasma 5.5.3 is out and this bug appears to be getting worse - not better.
Up until now the klipper icon in the tray has never been effeced - but now in
5.5.3 on every boot I am getting less than half a klipper icon.
toggling system services in tray settings restores a full icon.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-pa] [Bug 352055] plasma-pa plasmoid not shown in systemtray after startup

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352055

Mark  changed:

   What|Removed |Added

 CC||mrkf...@yahoo.co.nz

--- Comment #52 from Mark  ---
definitely not just plasma-pa
while plasma-pa is not there on almost every reboot my ibus icon is also not
shown - but much more randomly - probably on about 50% of reboots it isn't
there.
ibus is part of the "application status" part of sys tray so toggling that
setting gets it back.
I've observed this bug consistently from plasma 5.4.2 through to 5.5.1 on
openSUSE Leap

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 355015] SFTP: Can't browse files on phone using kdeconnect-kde5

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=355015

--- Comment #3 from Mark  ---
this bug is still present for me running kdeconnect-kde5 0.9.0-3.3 with my
Nexus 5 running Android 6.0.1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 355015] SFTP: Can't browse files on phone using kdeconnect-kde5

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=355015

--- Comment #4 from Mark  ---
Created attachment 96029
  --> https://bugs.kde.org/attachment.cgi?id=96029=edit
Dolphin

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 356469] lockscreen is broken on plasma 5.5

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356469

--- Comment #3 from Mark  ---
truly not there.
With compositor suspended there is still no way to re-enter DE

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksmserver] [Bug 356469] lockscreen is broken on plasma 5.5

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356469

Mark  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Mark  ---
ok - seems this was an openSUSE packaging error that has now been fixed
http://lists.opensuse.org/opensuse-kde/2015-12/msg00019.html

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 356469] lockscreen is broken on plasma 5.5

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356469

--- Comment #1 from Mark  ---
Created attachment 95976
  --> https://bugs.kde.org/attachment.cgi?id=95976=edit
lock screen in leap 42.1 plasma 5.5

sorry about the poor image quality

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 356469] New: lockscreen is broken on plasma 5.5

[Mark via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356469

Bug ID: 356469
   Summary: lockscreen is broken on plasma 5.5
   Product: kwin
   Version: 5.5.0
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: backend-x11
  Assignee: kwin-bugs-n...@kde.org
  Reporter: mrkf...@yahoo.co.nz

opensuse Leap 42.1 with newly updated plasma 5.5
Lock screen set to activate after 45 mins which works just fine but once
lockscreen is activated there is no place to input a password to re-enter the
desktop - it simply displays a blank wallpaper screen.
Same behaviour if lockscreen invoked using ctrl+alt+L

please see
https://forums.opensuse.org/showthread.php/511703-plasma-5-5-can-t-access-sddm-settings?p=2742046#post2742046

-- 
You are receiving this mail because:
You are watching all bug changes.