date:20170803

Re: libqaccessibilityclient now in kdereview

2017-08-03 Thread Christoph Feck


On 25.07.2017 13:25, Jonathan Riddell wrote:

libqaccessibilityclient is now in kdereview.


The autotests need Qt5Test, but if the dependency is not installed, 
building fails silently.

Either require Qt5Test, or make the tests optional if Qt5Test was not found.

Issue found by Fabian from openSUSE.

Re: hanging in kdialog

2017-08-03 Thread Jos van den Oever

This issue is showing up for other users too:

https://bugs.kde.org/show_bug.cgi?id=381693
https://bbs.archlinux.org/viewtopic.php?id=227681
https://www.reddit.com/r/kde/comments/6nqlul/
konsole_hangs_when_nothing_is_listening_on/
https://forum.antergos.com/topic/7254/notification-daemon-not-running-time-out-causes-thunar-to-hang

Cheers,
Jos

Op maandag 31 juli 2017 08:55:11 CEST schreef Jos van den Oever:
> Op zondag 30 juli 2017 10:25:39 CEST schreef u:
> > There's a review requests from me on KNotification that fixes this.
> 
> Which one is that? I know dvratil submitted one to fix a timeout issue that
> makes knotifications think it is connected to a notifications service when
> it is not.
> 
> The issue I'm seeing is that when you run on a desktop with plasma
> installed, plasma will install a fake dbus service (plasma_waitforname) for
> org.freedesktop.Notifications.
> 
> This 'service' assumes that plasma is starting up and does nothing but wait
> for plasma to become available. This assumption is wrong when the user has
> plasma installed but is currently running a different desktop for which
> there is no org.freedesktop.Notifications or for which
> org.freedesktop.Notifications has not started yet.
> 
> A 'solution' is to deinstall plasma_waitforname, but that's not a nice for a
> user that likes to have multiple desktops installed. Another workaround is
> to hard delete plasma_waitforname or org.kde.plasma.Notifications.service.
> > For a temporary fix, disable whatever notification kdialog is using from
> > systemsettings.
> 
> I'm not sure that is a fix. Does this affect knotifications and stop it from
> sending the notification or does it still send it via dbus and then let
> plasma determine whether or not to show / play the notification?
> 
> > Or start a notification daemon, or remove the plasma notification service
> > file in the dbus service dir.
> 
> That might be an option. I see a whole list here:
>   https://wiki.archlinux.org/index.php/Desktop_notifications
> 
> How would the system know which StartServiceByName to start if multiple
> services have been installed?
> 
> https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-start-> 
> service-by-name
> 
> I realize that the current behavior comes from the desire to have no naked
> notifications when plasma starts. Perhaps it is better to move the dbus
> registration of org.freedesktop.Notifications forward instead of relying on
> a binary like plasma_waitforname.
> 
> Cheers,
> Jos
> 
> > David
> > 
> > On 30 Jul 2017 09:22, "Jos van den Oever"  wrote:
> > > Hi all,
> > > 
> > > KDialog can get stuck waiting for some dbus reply in certain setups.
> > > Here
> > > is a
> > > short command-line that demonstrates this.
> > > 
> > > docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -ti --rm
> > > kdeneon/plasma:dev-unstable kdialog --msgbox 'wait for it'
> > > 
> > > This runs kdialog in a docker environment. Some services are not
> > > available
> > > there. The hang is due to a KNotification as you can see from the
> > > backtrace.
> > > 
> > > I've also attached the output from dbus-monitor with an indication of
> > > where
> > > the hang starts.
> > > 
> > > Not all arguments to kdialog have this problem. Only the ones that try
> > > to
> > > start org.freedesktop.Notifications.
> > > 
> > > Shouldn't that call fail faster?
> > > 
> > > Cheers,
> > > Jos
> > > 
> > > neon@fecce5c790e0:~$ gdb /usr/bin/kdialog
> > > GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
> > > Copyright (C) 2016 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later  > > html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.  Type "show
> > > copying"
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-linux-gnu".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > .
> > > Find the GDB manual and other documentation resources online at:
> > > .
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from /usr/bin/kdialog...(no debugging symbols
> > > found)...done.
> > > (gdb) run --msgbox hi
> > > Starting program: /usr/bin/kdialog --msgbox hi
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library
> > > "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > > [New Thread 0x7f2e96ec8700 (LWP 166)]
> > > [New Thread 0x7f2e8f5a9700 (LWP 167)]
> > > ^Z
> > > Thread 1 "kdialog" received signal SIGTSTP, Stopped (user).
> > > pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/
> > > pthread_cond_wait.S:185
> > > 185 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such
> > > file or
> > > directory.
> >

Re: Elisa is in kdereview

2017-08-03 Thread Matthieu Gallien

Hello,

On samedi 29 juillet 2017 11:47:03 CEST Albert Astals Cid wrote:
> El dilluns, 17 de juliol de 2017, a les 11:22:15 CEST, Matthieu Gallien va
> 
> escriure:
> > Hello,
[...]
> > 
> > I am still working on improving those lacking areas. I am currently
> > integrating KConfig for configuration especially of the file indexers.
> > The next step is to provide more user notifications about what happen (and
> > not just a busy indicator when waiting music to be indexed).
> > Due to holydays and being busy with real life, this could take a few weeks
> > to land in a finished state. Should Elisa stay in review or move back to
> > playground ?
> 
> At Akademy we codified a project should not stay in kdereview for more than
> two months, this should give you some rule of thumb of whether we should
> bring it back to playground or not.

Thanks for the information.

I think I will request to move back to playground since I am sure that the 
maximum delay will be reached by Elisa even if I finish fixing the reported 
issues quickly ?

I am sorry for the extra work for others.

Best regards

> Cheers,
>   Albert
> 
> > > User experience quirks aside, Elisa seems to be in really good shape.*
> > > Builds. Plays music. I18n seems to be in order as well.
> > > 
> > > HS
> > 
> > Thanks for your review and sorry for the late reply.
> > 
> > Best regards

Re: hanging in kdialog

2017-08-03 Thread Jos van den Oever

Op zondag 30 juli 2017 10:25:39 CEST schreef u:
> There's a review requests from me on KNotification that fixes this.

Which one is that? I know dvratil submitted one to fix a timeout issue that 
makes knotifications think it is connected to a notifications service when it 
is not.

The issue I'm seeing is that when you run on a desktop with plasma installed, 
plasma will install a fake dbus service (plasma_waitforname) for 
org.freedesktop.Notifications.

This 'service' assumes that plasma is starting up and does nothing but wait 
for plasma to become available. This assumption is wrong when the user has 
plasma installed but is currently running a different desktop for which there 
is no org.freedesktop.Notifications or for which org.freedesktop.Notifications 
has not started yet.

A 'solution' is to deinstall plasma_waitforname, but that's not a nice for a 
user that likes to have multiple desktops installed. Another workaround is to 
hard delete plasma_waitforname or org.kde.plasma.Notifications.service.

> For a temporary fix, disable whatever notification kdialog is using from
> systemsettings.

I'm not sure that is a fix. Does this affect knotifications and stop it from 
sending the notification or does it still send it via dbus and then let plasma 
determine whether or not to show / play the notification?

> Or start a notification daemon, or remove the plasma notification service
> file in the dbus service dir.

That might be an option. I see a whole list here:
  https://wiki.archlinux.org/index.php/Desktop_notifications

How would the system know which StartServiceByName to start if multiple 
services have been installed?

https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-start-service-by-name

I realize that the current behavior comes from the desire to have no naked 
notifications when plasma starts. Perhaps it is better to move the dbus 
registration of org.freedesktop.Notifications forward instead of relying on a 
binary like plasma_waitforname.

Cheers,
Jos

> 
> David
> 
> On 30 Jul 2017 09:22, "Jos van den Oever"  wrote:
> > Hi all,
> > 
> > KDialog can get stuck waiting for some dbus reply in certain setups. Here
> > is a
> > short command-line that demonstrates this.
> > 
> > docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -ti --rm
> > kdeneon/plasma:dev-unstable kdialog --msgbox 'wait for it'
> > 
> > This runs kdialog in a docker environment. Some services are not available
> > there. The hang is due to a KNotification as you can see from the
> > backtrace.
> > 
> > I've also attached the output from dbus-monitor with an indication of
> > where
> > the hang starts.
> > 
> > Not all arguments to kdialog have this problem. Only the ones that try to
> > start org.freedesktop.Notifications.
> > 
> > Shouldn't that call fail faster?
> > 
> > Cheers,
> > Jos
> > 
> > neon@fecce5c790e0:~$ gdb /usr/bin/kdialog
> > GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later  > html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/bin/kdialog...(no debugging symbols
> > found)...done.
> > (gdb) run --msgbox hi
> > Starting program: /usr/bin/kdialog --msgbox hi
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > [New Thread 0x7f2e96ec8700 (LWP 166)]
> > [New Thread 0x7f2e8f5a9700 (LWP 167)]
> > ^Z
> > Thread 1 "kdialog" received signal SIGTSTP, Stopped (user).
> > pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/
> > pthread_cond_wait.S:185
> > 185 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such
> > file or
> > directory.
> > (gdb) back
> > #0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/
> > x86_64/
> > pthread_cond_wait.S:185
> > #1  0x7f2ea54cf8eb in QWaitCondition::wait(QMutex*, unsigned long) ()
> > from
> > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> > #2  0x7f2ea8375e54 in ?? () from /usr/lib/x86_64-linux-gnu/
> > libQt5DBus.so.5
> > #3  0x7f2ea8331aa1 in ?? () from /usr/lib/x86_64-linux-gnu/
> > libQt5DBus.so.5
> > #4  0x7f2ea831e6cb in QDBusConnection::call(QDBusMessage const&,
> > QDBus::CallMode, int) const () from /usr/lib/x86_64-linux-gnu/
> > libQt5DBus.so.5
> > #5  0x7f2ea833c862 in
> > QDBusAbs

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

2017-08-03 Thread Gregor Mi


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128854/
---

(Updated Aug. 3, 2017, 1:25 p.m.)


Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, 
Thomas Lübking, and Thomas Pfeiffer.


Changes
---

just capture "this"


Repository: libksysguard


Description
---

This adds a new "Tools" button to the ksysguard widget which contains entries 
to related tools:

- Run Command --> starts KRunner to execute a command
- KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts 
the lightweight System Monitor which has less features)
- Info Center --> starts the Info Center which shows additional system 
information
- Htop --> starts htop
- Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. The 
displayed shortcut is the one set in Global Keyboard Shortcuts. Currently, this 
shortcut is shown in the End Process... button tooltip but there it is 
hard-coded.

This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/


Diffs (updated)
-

  CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 
  processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e 
  processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
  processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 

Diff: https://git.reviewboard.kde.org/r/128854/diff/


Testing
---

- test if all tools start correctly
- check if a changed shortcut for Kill Window is shown in the tools menu (see 
screenshot)
- check if for example htop is not installed that there is no menu item for it


File Attachments


screenshot of the new Tools button
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png


Thanks,

Gregor Mi

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

2017-08-03 Thread Kevin Funk



> On July 31, 2017, 9:11 a.m., Kevin Funk wrote:
> > processui/ksysguardprocesslist.cpp, line 354
> > 
> >
> > Why this?
> 
> Gregor Mi wrote:
> When I try to capture "d", then I get the following compiler error:
> 
> processui/ksysguardprocesslist.cpp:355:36: error: capture of non-variable 
> ‘KSysGuardProcessList::d’ 
> 
> I also find the current solution a bit strange. See here: 
> https://stackoverflow.com/questions/12944002/capture-by-value-class-members 
> (C++14 might solve the issue)

Just capture `[this]`. `d` is visible then.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128854/#review103512
---


On Aug. 3, 2017, 11:08 a.m., Gregor Mi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128854/
> ---
> 
> (Updated Aug. 3, 2017, 11:08 a.m.)
> 
> 
> Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, 
> Thomas Lübking, and Thomas Pfeiffer.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This adds a new "Tools" button to the ksysguard widget which contains entries 
> to related tools:
> 
> - Run Command --> starts KRunner to execute a command
> - KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts 
> the lightweight System Monitor which has less features)
> - Info Center --> starts the Info Center which shows additional system 
> information
> - Htop --> starts htop
> - Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. 
> The displayed shortcut is the one set in Global Keyboard Shortcuts. 
> Currently, this shortcut is shown in the End Process... button tooltip but 
> there it is hard-coded.
> 
> This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 
>   processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e 
>   processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
>   processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 
> 
> Diff: https://git.reviewboard.kde.org/r/128854/diff/
> 
> 
> Testing
> ---
> 
> - test if all tools start correctly
> - check if a changed shortcut for Kill Window is shown in the tools menu (see 
> screenshot)
> - check if for example htop is not installed that there is no menu item for it
> 
> 
> File Attachments
> 
> 
> screenshot of the new Tools button
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

2017-08-03 Thread Gregor Mi


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128854/
---

(Updated Aug. 3, 2017, 11:08 a.m.)


Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, 
Thomas Lübking, and Thomas Pfeiffer.


Changes
---

* The Plasma requirement in CMakeLists.txt was not needed


Repository: libksysguard


Description
---

This adds a new "Tools" button to the ksysguard widget which contains entries 
to related tools:

- Run Command --> starts KRunner to execute a command
- KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts 
the lightweight System Monitor which has less features)
- Info Center --> starts the Info Center which shows additional system 
information
- Htop --> starts htop
- Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. The 
displayed shortcut is the one set in Global Keyboard Shortcuts. Currently, this 
shortcut is shown in the End Process... button tooltip but there it is 
hard-coded.

This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/


Diffs (updated)
-

  CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 
  processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e 
  processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
  processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 

Diff: https://git.reviewboard.kde.org/r/128854/diff/


Testing
---

- test if all tools start correctly
- check if a changed shortcut for Kill Window is shown in the tools menu (see 
screenshot)
- check if for example htop is not installed that there is no menu item for it


File Attachments


screenshot of the new Tools button
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png


Thanks,

Gregor Mi

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

2017-08-03 Thread Gregor Mi



> On July 31, 2017, 9:11 a.m., Kevin Funk wrote:
> > processui/ksysguardprocesslist.cpp, line 354
> > 
> >
> > Why this?

When I try to capture "d", then I get the following compiler error:

processui/ksysguardprocesslist.cpp:355:36: error: capture of non-variable 
‘KSysGuardProcessList::d’ 

I also find the current solution a bit strange. See here: 
https://stackoverflow.com/questions/12944002/capture-by-value-class-members 
(C++14 might solve the issue)


- Gregor


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128854/#review103512
---


On July 28, 2017, 12:20 p.m., Gregor Mi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128854/
> ---
> 
> (Updated July 28, 2017, 12:20 p.m.)
> 
> 
> Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, 
> Thomas Lübking, and Thomas Pfeiffer.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This adds a new "Tools" button to the ksysguard widget which contains entries 
> to related tools:
> 
> - Run Command --> starts KRunner to execute a command
> - KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts 
> the lightweight System Monitor which has less features)
> - Info Center --> starts the Info Center which shows additional system 
> information
> - Htop --> starts htop
> - Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. 
> The displayed shortcut is the one set in Global Keyboard Shortcuts. 
> Currently, this shortcut is shown in the End Process... button tooltip but 
> there it is hard-coded.
> 
> This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 
>   processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e 
>   processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
>   processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 
> 
> Diff: https://git.reviewboard.kde.org/r/128854/diff/
> 
> 
> Testing
> ---
> 
> - test if all tools start correctly
> - check if a changed shortcut for Kill Window is shown in the tools menu (see 
> screenshot)
> - check if for example htop is not installed that there is no menu item for it
> 
> 
> File Attachments
> 
> 
> screenshot of the new Tools button
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

2017-08-03 Thread Gregor Mi



> On July 31, 2017, 9:11 a.m., Kevin Funk wrote:
> > CMakeLists.txt, line 21
> > 
> >
> > libksysguard should not require Plasma, it should stay optional at best.
> > 
> > See one line below in that CMakeLists.txt...

You are right. The Plasma requirement is not needed. I'll remove it.


- Gregor


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128854/#review103512
---


On July 28, 2017, 12:20 p.m., Gregor Mi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128854/
> ---
> 
> (Updated July 28, 2017, 12:20 p.m.)
> 
> 
> Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, 
> Thomas Lübking, and Thomas Pfeiffer.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This adds a new "Tools" button to the ksysguard widget which contains entries 
> to related tools:
> 
> - Run Command --> starts KRunner to execute a command
> - KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts 
> the lightweight System Monitor which has less features)
> - Info Center --> starts the Info Center which shows additional system 
> information
> - Htop --> starts htop
> - Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. 
> The displayed shortcut is the one set in Global Keyboard Shortcuts. 
> Currently, this shortcut is shown in the End Process... button tooltip but 
> there it is hard-coded.
> 
> This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 
>   processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e 
>   processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
>   processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 
> 
> Diff: https://git.reviewboard.kde.org/r/128854/diff/
> 
> 
> Testing
> ---
> 
> - test if all tools start correctly
> - check if a changed shortcut for Kill Window is shown in the tools menu (see 
> screenshot)
> - check if for example htop is not installed that there is no menu item for it
> 
> 
> File Attachments
> 
> 
> screenshot of the new Tools button
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

Re: libqaccessibilityclient now in kdereview

Re: hanging in kdialog

Re: Elisa is in kdereview

Re: hanging in kdialog

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

Re: Review Request 128854: Add a Tools button above the process list of System Monitor

9 matches

Site Navigation

Mail list logo

Footer information