Isn't it possible to the annotator? In ksnip it's hidden as long as you have no screenshot, so ksnip on startup is basically a toolbar.

In D22074#650858, @davidre wrote:

The reason that the spectacle window is larger on start because the annotator cannot be smaller because of the annotation tools sidebar I think

In D22074#598803, @dporobic wrote:

All commits for kColorPicker:

kColorPicker.tar.gz39 KBDownload

Meanwhile there have been some updates to kImageAnnotator, maybe you want to add them too, even tough some unit tests are currently broken, I need to fix them, so potentially more commits coming.

kImageAnnotator-latest.tar.gz57 KBDownload

All commits for kColorPicker:

Whats the process for adding new Widgets to KWidgetsAddons?

kImageAnnotator got its KDE Repo https://cgit.kde.org/libkimageannotator.git/

Should we move kColorPicker to KDE infrastructure too?
https://github.com/DamirPorobic/kColorPicker

Ok, lets start with the repository (I prefer GitLab as I have some experience with it) and bug tracker. Where can I log a sysadmin task?

What exactly do you mean with none-KDE version?

I've finished the work on the shared library stuff and I'm already using it in ksnip, where you can test the latest version. Guess as @gregormi said, someone should probably start porting it to KDE infrastructure. I'm currently still working on some bugs and and new features so if someone has spare time, that is probably where to start @ngraham .

Hey Nate,

I have disabled the shadow for marker in the recent version and also added some different default colors for the tools. The build error that we had is also fixed.
Thanks for the tip with deepin-screenshot, I'll have a look into it.

Yeah, it's a bit odd when the handles indicate all items will be affected, while actually only one item will be resized.

I've fixed that now, hiding only the one that is currently resizing.

The only thing that's a bit inconsistent is that for moving the handles disappear on mouse-down already (like in Gwenview), but for resizing they hide only when starting to move the cursor (unlike in Gwenview). I'd prefer the former behaviour.

@rkflx thanks for confirming.

First I though about going with the second option but got to the same point you got in your edit. Then I remembered about about translating the painter which I read bout in a Qt bug and this could actually work, here the result:

I don't know if I get you correctly but to me this looks like an Antialiasing issue.
Here with enabled Antialiasing

In T6321#145897, @rkflx wrote:

Thanks logging those issues! (Once the code lives in KDE's repos, we should probably use tasks on Phabricator for tracking…)

Sure, for now I only use them for myself and it's easier for me to track them in github, and the project lives there currently.

I noticed a more general problem which might be related: Try drawing straight lines (modifier FTW ;) with 1/2/3/4px width next to each other and look at them with KMag. They are not really aligned to the pixel grid, so Qt uses anti-aliasing, resulting in different colours and line widths. I think that's important to solve first, and afterwards focus on polishing the rectangle outlines or try a different approach if that fails.

@rkflx do you have a CI that builds on every commit? xD
That was another refactoring, should be working again.

@rkflx the slow test build should be fixed now. The initial approach has build all the source for every source file, now we build the source as a library once and link it to every test.

@rkflx are you using latest version? I have fixed those error yesterday commit

It's not obvious enough. You could have just changed the colours of those items to a lighter shade.

It's not the same, with this approach you see selected items that are hidden behind other items and the color could be any color of course.

@huoni how about something like this for selected items:

Thanks for the feedback :)

@rkflx @huoni
I've added few more things, like multiple item selection/delete/move, bring selected items to front/back, different cursors for hover over items and resize, snap-to for creating items (hold ctrl), toggle selection (hold ctrl), preciser hit detection (we count now only hit on shape, if item has no file, the inner space is not accounted as item).

Yeap, that looks nice, that is the kind of control I was hopping to implement. I'll look later into implementing something like this (or the exact think) in KWidgetsAddons, when we get to the fine-tuning stuff.

Yeah, saving configuration and last screenshot option is saved by default though this can be disabled via settings. Same works in KImageAnnotator now, I'm using more or less the same approach.
The color grid works like: Load a predefined list of colors, after loaded, load last or default color for current tool, if the color doesn't exists in current grid, add the color to the grid. So basically all but the last selected custom color is cleared on startup. If you have selected one of the default colors, all custom colors are deleted after startup.

…now this also looks kinda neat. I guess that's because compared to your initial screenshot here the downwards pointing arrows are missing, making me wonder about usability for the user, though…

The initial screenshot is a QToolButton with menu. What I've added here is only a QToolButton that opens QColorDialog, which, in case we pick this approach, I would replace with a popup menu, that shows a grid with colors, similar to the one I have used in KSnip. We can show with or without arrow. KColorCombo is not very flexible as I can't set and custom icons so probably wouldn't use it. With the other option (one that looks and works like a combobox), I would make my own color combobox where I can set custom icons.

And here the button version, which for me personally fits/looks best (image different icons for the two pickers and some nicer ordering):

I would definitely go with two row tools when we put the properties stuff down there, I do not like the space there too.

I've been playing around with the color picker, tried out KColorCombo and some custom stuff. Does this look anything useful? With the icon left from the Combobox it seems a bit too wide. Below for the size picker another option, custom adding icon into the combobox, something like they have in LibreOffice Draw, we could make the same for the color picker.

I agree that three color settings might be an overkill for simply annotating a screenshots but I think that we need two, at least for the text and numbering tool as @huoni explained.

How about something like this instead of a new UI for editing screenshots with Spectacle: https://github.com/lupoDharkael/flameshot/blob/master/img/appPreview/animatedUsage.gif

Update:
I was not happy with the KColourPaint style so I went more in direction of LibreOffice Draw, I'm trying out not this approach, here is how it looks like:

Can we in Phabricator somehow track open tasks? I would like to have a list of stuff that is planned and will come eventually in future, we could use the to prioritize and track progress. Other folks would be able to see what is planned and what note and eventually add wishes. Something like sub-tasks. How do you handle stuff like that?

Instead of PNGs, we can probably find some SVG icons in Breeze or try to request missing ones.

Agreed. Current icons don't adapt to dark themes :)

@rkflx Thanks for the detailed feedback :)

I've made a prototype for the Image Annotator, nothing fancy, four annotation items, selection, resizing and deleting. I wanted to test how I could achieve the item resizing and I think that works fine now, so I will slowly turn that into a working application/widget.

Nice, I'll start work on this, hopefully before weekend. I believe we can quickly have some basic functionality for first thought.

I came to the conclusion though, that this component/framework probably won't be so generic to be called "KImageEditor" but rather "KScreenshotEditor" or "KAnnotateImageEditor"

Assume we want to annotate something in Gwenview or Skanlite: Certainly we would not want to replace Gwenview's advanced image display component completely

I think I'm a fan of the annotation widget approach. Later on we could replace the preview window with the annotation widget.
Someone mentioned KParts earlier, I haven't worked with it yet but that could be something suitable as fart as I can tell from my quick googeling. Would be nice to have someone with experience with KParts to give kick start or at least point me in the right direction.

Ok, that would go in direction of being an annotation "widget" that you could use basically anywhere, interesting idea.

@rkflx
Ok, so we go for now with a separate window, it's not the perfect solution but it might be our best bet for now and we could change stuff in the future when we have some foundation.

@rkflx Thank you for your detailed feedback!

If no one is working on this task I would take it and see what I can do.

In D4483#85649, @dporobic wrote:

Changed formatting as suggested. If it's ok now could you please commit the patch, I don't have commit rights?

Changed formatting as suggested. If it's ok now could you please commit the patch, I don't have commit rights?

More formatting and style cleanup as suggested by mwolff

Moved must of the functionality to single free function in separate namespace. Some additional cleanup as suggested by mwolff

Sure, damir_porobic(at)live(dot)com would be the address and name is Damir Porobic.

In D4334#81627, @mwolff wrote:

one minor nitpick, otherwise lgtm

do you have commit rights? if so, feel free to amend and push to master

Changed function name that changes the continue action properties from continueStartsDebug to setContinueStartsDebug

In D4334#81123, @mwolff wrote:

I am missing some things here, besides the nitpicks below:

The action's tooltip, and possibly even its icon, should now imo update depending on the state to indicate what action will be triggered when it is executed.

Can you implement that as well please?

Thanks

+ Added a function that changes the icon and text of the continue_debug action to look like launch_debug action depending on the debugger state.
+ Changed formatting as suggested by mwolff.

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