The change was submitted in the original pull request
Mon, May 13
Sorry for late answer...
Mon, May 6
I guess there was some kind of arcanist mistake when this became a separate review request and not an update to D21024 (Rudimentary xml/html parser for symbolviewer plugin)
Sun, May 5
Good addition :)
Fri, May 3
This is not an issue on Windows (yet?) as the whole konsole plugin is disabled on Windows.
Mon, Apr 29
That particular class is yours :)
My name does not need to be in there since I have not touched that file yet ;)
Sun, Apr 28
I do not have strong opinion about the with of the line, it just hit me that it might become a bit narrow...
So to get nice icons on buttons we need to "setAttribute(Qt::AA_UseHighDpiPixmaps);", but that blurs the previews -> devicePixelRatioF() for preview images.
Please fix the copyright owner and date of the files before committing.
Thu, Apr 25
Same ignorant question here as for libksane... Why do we need the HighDpiPixmaps in skanlite? The images get the dpi settings from the scanner setting...
Now I must show my ignorance... why do we need this devicePixelRatio in ksanevewer/selectionitem?
Apr 1 2019
Sorry, I thought i had answered, but I had forgotten to do it.
Mar 30 2019
Yes I also have a memory that there was a bug report about it, but I can't find it now....
Mar 29 2019
Mar 18 2019
Mar 14 2019
Mar 4 2019
This differential does three things
Mar 3 2019
Mar 2 2019
This is a good improvement idea for libksane. :)
Feb 20 2019
Kåre, could you comment my reply?: https://phabricator.kde.org/D18966#411134
Feb 12 2019
The idea is sane :)
Can you also return false in setOptVal() in case the scanning is ongoing? (and the corresponding note in the doxygen comments)
Feb 11 2019
The idea is good. Could we have setOptVals() return -1 and setOptVal() false if the scanning is ongoing and the delayed setting of the value implemented in Skanlite?
OK this can go in.
Feb 10 2019
Just these minor adjustments and we are there.
Feb 6 2019
Feb 4 2019
Jan 29 2019
Sorry, busy month... new project at work and got a new computer to configure....
Jan 22 2019
I think the selection if we save through the PNG 16bit/color or QImage version should be done in Skanlite.cpp not in savePng().
Jan 16 2019
Jan 15 2019
- Yes the "more option" button is a bit far away. At some point it actually was at the right of all the options. That is a real possibility
Sorry for the late response. A lot of real life activities....
Jan 13 2019
My personal taste would be to only have a small tool-tip saying: See the "Add.." context menu entry for regular expression help.
- These buttons are different than the other buttons in that they modify the UI of the toolview but not the search. So mixing them is maybe not the best? One could think about moving them to the right side of the other buttons and have some type of separator between...
I would be OK with the addition of F6 and Shift+F6 to the Search plugin, but I think it would be good to have a plan for all the shortcuts and update all at once....
I'm not entirely sure removing the feature of having the lookup word in the menu is an improvement, but I just noticed that the feature is broken and only works when a word is selected.
Jan 9 2019
I'm OK with this repaint() and if you want I'm also OK with having the processEvents() until we move the actual saving to a separate thread.
Jan 8 2019
I really like the idea! :)
But this all is to just re-paint one time before we freeze for the time it takes to save of the file? Would it be better in the long run to think about moving the saving to a thread?
Jan 7 2019
I'm OK with parent->repaint()
I have not had the time to review this properly sorry :(
Besides the processEvents() I'm OK with this! :)
Jan 4 2019
Adding as a warning message in the view could be another review and needs comments from others first
Hmm... this is only done for local paths. If we only support this feature for local paths it would be much simpler to just use QDir::mkpath(), but it would be nice if it worked for remote folders too...
Jan 3 2019
@dhaumann OK the limit is too low for Kile that is clear. Visual Studio Code is limiting the highlighting on a line to 10000 characters.
Dec 31 2018
The new limit is now limiting the number of characters highlighted on a line. It is only the rest of the line that is not highlighted. This is IMO nicer as you don't see the non-highlighted part at the beginning of the line. The highlighting makes it a bit slower, so I decreased the limit to 512.
Disable highlighting after [limit] characters on a line in stead of the whole line.
Dec 28 2018
Dec 23 2018
I think this is fine, but let Christoph and Dominik decide if we want style fixing commits.
Dec 20 2018
Dec 19 2018
@shubham I'm wondering about the original issue that you try to fix with this review request. Why do we need a dialog that warns that there are multiple documents open in Kate when we close it?
Sorry Christmastime is a bit busy...
Dec 16 2018
Dec 15 2018
Changing the next/previous slots to go to the items with line numbers would be a good change.
I'm not sure why you have to move the setFocus() call to the beginning of the function... your comment says something about selection...
I think one magic build name is not the best way to enable auto-hiding.
Dec 10 2018
Sorry, I was a bit busy when this review came and then I forgot about it :(
Dec 9 2018
Dec 8 2018
Wouldn't it be better to make it possible to configure the current CppCheck in stead of adding a new one?
@zetazeta I'm not sure the highlighting length limit is worth an option as the editing of the document is not effected. I it is just a bit inconvenient that the highlighting disappears...
@dhaumann: You are right, the highlighting of the document still takes place and it is only KateRenderer that stops using the highlighting info for all lines longer than 1024 characters. All shorter lines are highlighted.
- Use a bit different config key to force a value reset for the limit.
- Fix reading the config value.
- Update the line-highlight disabled info message and position.
Dec 7 2018
There is not much else we can do than just have a dummy like this, with the current state of the twain wrapper.
Sorry! This problem has totally passed me by before this... I'll have a look.
Dec 6 2018
The highlighting limit is now returned in a function in KateRenderer as it is used also in katedocument.cpp for the warning/information message.
Add a message to inform about why the lines are not highlighted.
Add a note about disabled highlighting to the wrapped lines warning.
Increase the default line length limit to 100 000 characters per line.
Now I committed to master. Should I back-ported it to 18.12?
I guess there are no objections to commit this :)
OK, I have used this patch actively for a week now, and I have not noticed any regression... ;)
Remove unneeded temporary
Dec 4 2018
I agree, we need to do something about the line length limit (that only wraps the lines at the limit when opening the file).
Dec 3 2018
It is maybe not optimal to "hide" a bug fix among a bunch of code cosmetics, but the fix is good :)