D20697: Review IconBorder

[loh tar]

loh.tar added a comment.


  @dhaumann Beside these annotation stuff I think I'm done with this now. 
Should you, or someone else, not stop me in the next few days I may treat this 
as OK and push it.
  There are still some issues in the mouse move handling but will try to fix 
that in some other patch

REVISION DETAIL
  https://phabricator.kde.org/D20697

To: loh.tar, #ktexteditor, dhaumann
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars

D20697: Review IconBorder

[loh tar]

loh.tar edited the test plan for this revision.

REVISION DETAIL
  https://phabricator.kde.org/D20697

To: loh.tar, #ktexteditor, dhaumann
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars

D20697: Review IconBorder

[loh tar]

loh.tar updated this revision to Diff 56694.
loh.tar edited the summary of this revision.
loh.tar added a comment.


  - Fix bookmark pixmap painting
  
  Left before, right with fix
  F6786476: bookmark-pixmap.png 

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20697?vs=56693=56694

REVISION DETAIL
  https://phabricator.kde.org/D20697

AFFECTED FILES
  src/view/kateviewhelpers.cpp
  src/view/kateviewhelpers.h

To: loh.tar, #ktexteditor, dhaumann
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars

D20697: Review IconBorder

[loh tar]

loh.tar updated this revision to Diff 56693.
loh.tar edited the summary of this revision.
loh.tar added a comment.


  - Add margin to the edit area, but I'm not sure if it should be done here. I 
guess renderer should do it
  - Simplify "additional folding highlighting", there is now the slightly 
gradient gone, bad?
  - Rename backGroundColor->iconBarColor to fit orig name, but that name sounds 
to me as it's only for the icon area of the border
  
  F6786421: pic.png 

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20697?vs=56644=56693

REVISION DETAIL
  https://phabricator.kde.org/D20697

AFFECTED FILES
  src/view/kateviewhelpers.cpp
  src/view/kateviewhelpers.h

To: loh.tar, #ktexteditor, dhaumann
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars

D20708: Change input-* device icon styles, add 16px icons

[Noah Davis]

ndavis added a comment.


  Actually, `dialog-input-devices` is used by inkscape for configuring pointing 
devices and tablets. AFAIK, only Inkscape uses that icon. If I made it show 
more types of devices, it would be more accurate to use a tablet. Looking at 
the Input Devices dock in Inkscape, it doesn't seem like it would be used much 
for configuring mice, so it might be better if it was just a symlink to the 
`input-tablet` icon.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20708

To: ndavis, #vdg
Cc: ngraham, kde-frameworks-devel, michaelh, bruns

D20708: Change input-* device icon styles, add 16px icons

[Noah Davis]

ndavis added a comment.


  In D20708#453690 , @ngraham wrote:
  
  > Overall very nice.
  >
  > Instead of symlinking `input-mouse` to `dialog-input-devices`, I think it 
might make more sense to rename `dialog-input-devices` to be `input-mouse` and 
then change the `dialog-input-devices` so that it depicts more than one input 
device, to reinforce its name. Maybe a mouse + keyboard?
  
  
  I don't think I can fit a whole keyboard, but I can probably fit a numpad.
  
  > While you're thinking about input device icons, we also have a few 
outstanding bugs:
  > 
  > - The colorful version of the mouse icon is hard to see on a dark 
background, and also it maybe should have a more generic appearance rather than 
looking like a Razer mouse: https://bugs.kde.org/show_bug.cgi?id=406453
  
  That will be a lot of work and I don't want to do that in this diff since 
it'll slow the rest of the changes down considerably. The most important change 
in this diff is that this is fixed (22px icon where 16px should be): F6786267: 
Screenshot_20190421_215747.png 
  
  > - We need a joystick icon that actually looks like a joystick: 
https://bugs.kde.org/show_bug.cgi?id=406679
  
  I'll do that with the 64px mouse icon fix when I get around to it.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20708

To: ndavis, #vdg
Cc: ngraham, kde-frameworks-devel, michaelh, bruns

D20169: Add profile support interface for TerminalInterface

[Maximilian Schiller]

mschiller added a comment.


  > wrt getProfilePath: what if an application does not store a profile as 
single filename, for example as directory, or even stored e.g. in a DB? maybe 
it would be better to have this as property of a profile
  
  Yeah Konsole Profiles seem to already have a path property in the profile 
implementation. So gonna remove this.
  
  > is a setProfileProperty worth having?
  
  I don't think it would be good to have the user applications mess with the 
users customizations. In case the profile is somehow "incompatible" with the 
client application, exposing some profile management functions (e.g. copy and 
modify) might be useful but I can't think of an actual reason which would 
require that.
  
  > is an API to list the available properties worth having?
  
  Just to check at runtime if getting a property was successful returning an 
empty QVariant should be enough, because you need to look up the available 
properties to check the returned type anyway.

REPOSITORY
  R306 KParts

REVISION DETAIL
  https://phabricator.kde.org/D20169

To: mschiller, hindenburg, #konsole, #frameworks, cfeck, hein
Cc: pino, michaelh, ngraham, bruns

D20695: Add more icon sizes for audio, configure, distribute

[Nathaniel Graham]

ngraham accepted this revision.
ngraham added a comment.
This revision is now accepted and ready to land.


  Looks great, thanks!

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  add-new-size (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D20695

To: ndavis, #vdg, #plasma, ngraham
Cc: ngraham, kde-frameworks-devel, michaelh, bruns

D20169: Add profile support interface for TerminalInterface

[Pino Toscano]

pino added a comment.


  General notes on the API (not a konsole developer though):
  
  - an abstract virtual destructor is needed
  - in kdelibs/kf5 lingo, the "get" as prefix of API getters is generally not 
used
  - `setCurrentProfile` instead of `changeCurrentProfile`? the latter makes me 
think it does changes to the current profile, rather than setting another 
profile as current
  - wrt `changeCurrentProfile`: what will it do if the specified profile name 
does not exist? should the API return true/false to indicate the switch 
actually succeeded?
  - wrt `getProfilePath`: what if an application does not store a profile as 
single filename, for example as directory, or even stored e.g. in a DB? maybe 
it would be better to have this as property of a profile
  - is a `setProfileProperty` worth having?
  - is an API to list the available properties worth having?
  
  Also: this file is still not installed, so it cannot be used. Maybe just add 
the new interface to the existing `kde_terminal_interface.h`?

INLINE COMMENTS

> terminalprofileinterface.h:1
> +// interface.h
> +// Copyright (C)  2002  Dominique Devriese 

either put the right filename, or just remove (IMHO better)

> terminalprofileinterface.h:2
> +// interface.h
> +// Copyright (C)  2002  Dominique Devriese 
> +

this is certainly yours now

> terminalprofileinterface.h:19
> +
> +#ifndef KDELIBS_TERMINALPROFILEINTERFACE_H
> +#define KDELIBS_TERMINALPROFILEINTERFACE_H

I'd go with `KPARTS_etc` (instead of `KDELIBS_etc`)

REPOSITORY
  R306 KParts

REVISION DETAIL
  https://phabricator.kde.org/D20169

To: mschiller, hindenburg, #konsole, #frameworks, cfeck, hein
Cc: pino, michaelh, ngraham, bruns

D20536: Use consistent default Kickoff user icon

[Björn Feber]

This revision was automatically updated to reflect the committed changes.
Closed by commit R266:1c6e30d312c7: Use consistent default Kickoff user icon 
(authored by GB_2).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D20536?vs=56677=56678#toc

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20536?vs=56677=56678

REVISION DETAIL
  https://phabricator.kde.org/D20536

AFFECTED FILES
  icons-dark/applets/128/user-identity.svg
  icons-dark/applets/128/user-man.svg
  icons-dark/applets/22/user-identity.svg
  icons/applets/128/user-identity.svg
  icons/applets/128/user-man.svg
  icons/applets/22/user-identity.svg

To: GB_2, #plasma, #vdg, ngraham
Cc: ngraham, #vdg, kde-frameworks-devel, #plasma, michaelh, bruns

D20536: Use consistent default Kickoff user icon

[Björn Feber]

GB_2 updated this revision to Diff 56677.
GB_2 added a comment.


  Fix diff

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20536?vs=56263=56677

BRANCH
  arcpatch-D20536_1

REVISION DETAIL
  https://phabricator.kde.org/D20536

AFFECTED FILES
  icons-dark/applets/128/user-identity.svg
  icons-dark/applets/128/user-man.svg
  icons-dark/applets/22/user-identity.svg
  icons/applets/128/user-identity.svg
  icons/applets/128/user-man.svg
  icons/applets/22/user-identity.svg

To: GB_2, #plasma, #vdg, ngraham
Cc: ngraham, #vdg, kde-frameworks-devel, #plasma, michaelh, bruns

D20700: Add "edit-remove" icon symlink

[Nathaniel Graham]

ngraham added a comment.


  Yeah, I think the current minus icon is similar in that it's only meaningful 
next to a plus sign. So if we had a user interface with conjoined or adjacent 
plus and minus buttons, using that icon would make sense. But for removing a 
specific list item, I think this "X-style" icon is better. The trash can icon 
has a connotation of "this thing will be destroyed" that only applies to some 
list item removals.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: ngraham, ndavis, kde-frameworks-devel, #vdg, michaelh, bruns

D20169: Add profile support interface for TerminalInterface

[Maximilian Schiller]

mschiller updated this revision to Diff 56672.
mschiller edited the summary of this revision.
mschiller added a comment.


  Move the profile support to different class

REPOSITORY
  R306 KParts

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20169?vs=55201=56672

BRANCH
  terminal-interface-profiles (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D20169

AFFECTED FILES
  src/terminalprofileinterface.h

To: mschiller, hindenburg, #konsole, #frameworks, cfeck, hein
Cc: pino, michaelh, ngraham, bruns

D20708: Change input-* device icon styles, add 16px icons

[Nathaniel Graham]

ngraham added a comment.


  Overall very nice.
  
  Instead of symlinking `input-mouse` to `dialog-input-devices`, I think it 
might make more sense to rename `dialog-input-devices` to be `input-mouse` and 
then change the `dialog-input-devices` so that it depicts more than one input 
device, to reinforce its name. Maybe a mouse + keyboard?
  
  While you're thinking about input device icons, we also have a few 
outstanding bugs:
  
  - The colorful version of the mouse icon is hard to see on a dark background, 
and also it maybe should have a more generic appearance rather than looking 
like a Razer mouse: https://bugs.kde.org/show_bug.cgi?id=406453
  - We need a joystick icon that actually looks like a joystick: 
https://bugs.kde.org/show_bug.cgi?id=406679

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20708

To: ndavis, #vdg
Cc: ngraham, kde-frameworks-devel, michaelh, bruns

D20169: Add profile support interface for TerminalInterface

[Pino Toscano]

pino added a comment.


  Yes, this change breaks the binary compatibility.  Please add a 
TerminalInterfaceV2 that inherits TerminalInterface instead, or add a separate 
interface for profile handling.

REPOSITORY
  R306 KParts

REVISION DETAIL
  https://phabricator.kde.org/D20169

To: mschiller, hindenburg, #konsole, #frameworks, cfeck, hein
Cc: pino, michaelh, ngraham, bruns

D20169: Add profile support interface for TerminalInterface

[Maximilian Schiller]

mschiller edited the summary of this revision.

REPOSITORY
  R306 KParts

REVISION DETAIL
  https://phabricator.kde.org/D20169

To: mschiller, hindenburg, #konsole, #frameworks, cfeck, hein
Cc: michaelh, ngraham, bruns

D20700: Add "edit-remove" icon symlink

[Björn Feber]

GB_2 added a comment.


  In D20700#453658 , @ndavis wrote:
  
  > We have a problem where we don't use consistent iconography for "remove". 
Sometimes it's a normal minus, sometimes it's a red minus, sometimes it's a red 
X and sometimes it's a red trash can (the line between "delete" and "remove" 
can be blurry). I think adding an `edit-remove` icon would likely cause more 
confusion, first for developers and then for users. I don't think using a minus 
without a plus is a problem, but perhaps the minus should be made red?
  
  
  A trash can in a list like D20576  would 
look like you're deleting something entirely and a red minus would still have 
the context problem like I said. The GNOME HIG even has a rule for this 
(https://developer.gnome.org/hig/stable/icons-and-artwork.html):
  
  - Remember that some icons are only meaningful alongside other icons of the 
same type. For example, a media icon for stop is simply a square, and may not 
be identified as a stop icon without other media controls (like play, pause, or 
skip) being visible close by. Likewise, the icon to remove an item from a list 
is a subtract symbol (i.e. a single line), and will not be recognizable without 
a corresponding “plus” add icon.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: ndavis, kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

D20700: Add "edit-remove" icon symlink

[Noah Davis]

ndavis added a comment.


  In D20700#453565 , @GB_2 wrote:
  
  > `list-remove` is just a minus icon, which has no context and looks weird 
when used alone, without `list-add` next to it. An example where the new icon 
can be used is D20576 .
  
  
  We have a problem where we don't use consistent iconography for "remove". 
Sometimes it's a normal minus, sometimes it's a red minus, sometimes it's a red 
X and sometimes it's a red trash can (the line between "delete" and "remove" 
can be blurry). I think adding an `edit-remove` icon would likely cause more 
confusion, first for developers and then for users. I don't think using a minus 
without a plus is a problem, but perhaps the minus should be made red?

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: ndavis, kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

Re: May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

El diumenge, 21 d’abril de 2019, a les 17:47:47 CEST, Luigi Toscano va escriure:
> Christoph Feck ha scritto:
> > On 04/21/19 12:47, Albert Astals Cid wrote:
> >> We have a huge list of playground kde4 repos that are being processed for 
> >> l10n.
> >>
> >> This takes some resources that make no sense since you should really not 
> >> be 
> >> developing for KDE4 anymore, and if you really really really need it, it 
> >> shouldn't be in playground.
> >>
> >> So on May 10 i'll make sure scripty doesn't waste CPU on them.
> >>
> >> Cheers,
> >>   Albert
> >>
> >> P.S: Anyone interested in the list https://ghostbin.com/paste/823jo
> 
> Maybe we could move the code of everything-nepomuk and everything-plasma 4 to 
> unmaintained.

My immediate goal is not to waste CPU power processing old code every day for 
no reason, but yes, that probably makes sense too.

Cheers,
  Albert

> 
> > 
> > https://cgit.kde.org/smaragd.git/tree/CMakeLists.txt says that 
> > playground-artwork_smaragd is a KF5 repo. Where does the KDE4 detection 
> > come 
> > from?
> 
> trunk/l10n-kde4 tracks the "0.0" branch:
> 
> {"stable": "none", "trunk": "0.0", "stable_kf5": "none", "trunk_kf5": 
> "master"}
> 
> Happy Easter too!
> 
> Ciao
> 

D20702: KTar: Protect against negative longlink sizes

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R243 KArchive

REVISION DETAIL
  https://phabricator.kde.org/D20702

To: aacid, apol
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

Re: May 10: Removing l10n support for kde4 playground-* repos

[Luigi Toscano]

Christoph Feck ha scritto:

On 04/21/19 12:47, Albert Astals Cid wrote:

We have a huge list of playground kde4 repos that are being processed for l10n.

This takes some resources that make no sense since you should really not be 
developing for KDE4 anymore, and if you really really really need it, it 
shouldn't be in playground.


So on May 10 i'll make sure scripty doesn't waste CPU on them.

Cheers,
  Albert

P.S: Anyone interested in the list https://ghostbin.com/paste/823jo


Maybe we could move the code of everything-nepomuk and everything-plasma 4 to 
unmaintained.




https://cgit.kde.org/smaragd.git/tree/CMakeLists.txt says that 
playground-artwork_smaragd is a KF5 repo. Where does the KDE4 detection come 
from?


trunk/l10n-kde4 tracks the "0.0" branch:

{"stable": "none", "trunk": "0.0", "stable_kf5": "none", "trunk_kf5": "master"}

Happy Easter too!

Ciao
--
Luigi

D20708: Change input-* device icon styles, add 16px icons

[Noah Davis]

ndavis edited the summary of this revision.
ndavis edited the test plan for this revision.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20708

To: ndavis, #vdg
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D20708: Change input-* device icon styles, add 16px icons

[Noah Davis]

ndavis created this revision.
ndavis added a reviewer: VDG.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
ndavis requested review of this revision.

REVISION SUMMARY
  `devices/16` was missing some `input-*` icons.
  `input-keyboard-virtual` looked more like a wireless keyboard than a virtual 
keyboard. 
  Changed `input-keyboard*` style so that it could appear consistent at 16 and 
22px. It also looks a bit more like a real keyboard. 
  Made `configure-shortcuts` icon look good at 16px.

REPOSITORY
  R266 Breeze Icons

BRANCH
  input-icons (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D20708

AFFECTED FILES
  icons-dark/actions/16/configure-shortcuts.svg
  icons-dark/devices/16/input-keyboard-virtual.svg
  icons-dark/devices/16/input-keyboard.svg
  icons-dark/devices/16/input-mouse.svg
  icons-dark/devices/16/input-touchpad.svg
  icons-dark/devices/22/input-keyboard-virtual.svg
  icons-dark/devices/22/input-keyboard.svg
  icons-dark/devices/22/input-mouse.svg
  icons/actions/16/configure-shortcuts.svg
  icons/devices/16/input-keyboard-virtual.svg
  icons/devices/16/input-keyboard.svg
  icons/devices/16/input-mouse.svg
  icons/devices/16/input-touchpad.svg
  icons/devices/22/input-keyboard-virtual.svg
  icons/devices/22/input-keyboard.svg
  icons/devices/22/input-mouse.svg

To: ndavis, #vdg
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D20700: Add "edit-remove" icon symlink

[Björn Feber]

GB_2 added a comment.


  In D20700#453562 , @ndavis wrote:
  
  > Why does `list-remove` need an alternative?
  
  
  
  
  > alternative to list-remove, which needs to be next to list-add for context
  
  `list-remove` is just a minus icon, which has no context and looks weird when 
used alone, without `list-add` next to it. An example where the new icon can be 
used is D20576 .

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: ndavis, kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

D20700: Add "edit-remove" icon symlink

[Noah Davis]

ndavis added a comment.


  Why does `list-remove` need an alternative?

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: ndavis, kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

D20702: KTar: Protect against negative longlink sizes

[Aleix Pol Gonzalez]

apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R243 KArchive

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D20702

To: aacid, apol
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

Re: May 10: Removing l10n support for kde4 playground-* repos

[Christoph Feck]

On 04/21/19 12:47, Albert Astals Cid wrote:

We have a huge list of playground kde4 repos that are being processed for l10n.

This takes some resources that make no sense since you should really not be 
developing for KDE4 anymore, and if you really really really need it, it 
shouldn't be in playground.

So on May 10 i'll make sure scripty doesn't waste CPU on them.

Cheers,
  Albert

P.S: Anyone interested in the list https://ghostbin.com/paste/823jo


https://cgit.kde.org/smaragd.git/tree/CMakeLists.txt says that 
playground-artwork_smaragd is a KF5 repo. Where does the KDE4 detection 
come from?


Thanks, and Happy Easter,
Christoph Feck

D20700: Add "edit-remove" icon symlink

[Björn Feber]

GB_2 edited the summary of this revision.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

D20700: Add "edit-remove" icon symlink

[Björn Feber]

GB_2 retitled this revision from "Add "edit-remove" icon" to "Add "edit-remove" 
icon symlink".

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D20700

To: GB_2, #vdg
Cc: kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

D20700: Add "edit-remove" icon

[Björn Feber]

GB_2 updated this revision to Diff 56651.
GB_2 added a comment.


  Use symlinks: `edit-remove` -> `paint-none`

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20700?vs=56634=56651

BRANCH
  add-edit-remove-icon (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D20700

AFFECTED FILES
  icons-dark/actions/16/edit-remove.svg
  icons/actions/16/edit-remove.svg

To: GB_2, #vdg
Cc: kde-frameworks-devel, #vdg, michaelh, ngraham, bruns

May 10: Removing l10n support for kde4 playground-* repos

[Albert Astals Cid]

We have a huge list of playground kde4 repos that are being processed for l10n.

This takes some resources that make no sense since you should really not be 
developing for KDE4 anymore, and if you really really really need it, it 
shouldn't be in playground.

So on May 10 i'll make sure scripty doesn't waste CPU on them.

Cheers,
  Albert

P.S: Anyone interested in the list https://ghostbin.com/paste/823jo

D20264: Add test for "Auto Reload Document" option

[loh tar]

loh.tar added a comment.


  @dhaumann asked elsewhere
  
  > Instead of waiting so long, we could alternatively also have a while loop 
waiting up to 20 times for 50ms. This way, the test would be faster if possible.
  
  Like this?
  
diff --git a/autotests/src/katedocument_test.cpp 
b/autotests/src/katedocument_test.cpp
index 4be9d7c3..e24a8ad9 100644
--- a/autotests/src/katedocument_test.cpp
+++ b/autotests/src/katedocument_test.cpp
@@ -655,14 +655,23 @@ void KateDocumentTest::testAutoReload()
// without to wait before it doesn't work here. It mostly fails with 
500,
// it tend to work with 600, but is not guarantied to work even with 800
QTest::qWait(1000);
+// No idea how to do some slice test here

stream << "\nTest";
stream.flush();

- // Hardcoded delay m_modOnHdTimer in DocumentPrivate
+// Try not to waste more time than needed, but we need to wait
+const int timeSlice = 50;
+// Hardcoded delay m_modOnHdTimer in DocumentPrivate
// + min val with which it looks working reliable here
-QTest::qWait(200 + 800);
-QCOMPARE(doc.text(), "Hello\nTest");
+const int totalPatience = 200 + 800;
+
+QString refTxT = ("Hello\nTest");
+for (int w = 0; w <= totalPatience; w += timeSlice) {
+QTest::qWait(timeSlice);
+if (doc.text() == refTxT) break;
+}
+QCOMPARE(doc.text(), refTxT);
// ...stay in the last line after reload!
QCOMPARE(view->cursorPosition().line(), doc.documentEnd().line());

@@ -674,8 +683,12 @@ void KateDocumentTest::testAutoReload()
stream.flush();
file.close();

-QTest::qWait(200 + 800);
-QCOMPARE(doc.text(), "Hello\nTest\nWorld!");
+refTxT = ("Hello\nTest\nWorld!");
+for (int w = 0; w <= totalPatience; w += timeSlice) {
+QTest::qWait(timeSlice);
+if (doc.text() == refTxT) break;
+}
+QCOMPARE(doc.text(), refTxT);
// ...and ensure we have not move around
QCOMPARE(view->cursorPosition(), c);
}
  
  No Patch
  
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 3152ms
  
  With Patch
  
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 2619ms
533ms saved
  
  But it can still fail now :-(
  
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 3127ms
  
  also with increased waiting times
  
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 3787ms
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 4802ms
  
  Does maybe the check "if (doc.text() == " disturbs the nice waiting?
  Playing with longer slice shows an effect around a 500ms slice, but then we 
have no benefit
  
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 3147ms

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D20264

To: loh.tar, dhaumann, cullmann
Cc: cullmann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, 
michaelh, ngraham, bruns, demsking, sars, dhaumann

D20697: Review IconBorder

[loh tar]

loh.tar updated this revision to Diff 56644.
loh.tar added a comment.


  - Fix missing printed background in proper theme color
  - Fix scroll past end of document
  - Fix less pushy paint unfolded icon in not dark themes and don't try to use 
currentLineNumberColor, the folded icon gets also not highligted
  - Some more cosmetic
  
  F6785125: pic.png 

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20697?vs=56625=56644

REVISION DETAIL
  https://phabricator.kde.org/D20697

AFFECTED FILES
  src/view/kateviewhelpers.cpp
  src/view/kateviewhelpers.h

To: loh.tar, #ktexteditor, dhaumann
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars