[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Ian Wadham via KDE Bugzilla]

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

--- Comment #8 from Ian Wadham  ---
@Stefan: There are now two more configurable mouse actions: teleport pieces and
switch to close-up or distant view.  I followed the existing scheme, with
interactors, etc. because it seemed simpler to leave well enough alone.  Also
the config dialog is a handy lookup-table for users even if they never change
the default mouse actions.

One very nice thing about the current setup was that the functionality of
Palapeli's view and scene classes came for free with every piece holder window,
making it possible to do sub-assemblies within large puzzles in any window ---
main puzzle table or piece holder.

There is just one problem with the interactors as far as I am aware: they can
run on after a piece object has disappeared and cause a crash, e.g. in some
circumstances when merging pieces and always if you do Restart Puzzle (as a
keyboard shortcut) in the middle of a drag (which makes the crashes
reproducible).

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Stefan Majewsky via KDE Bugzilla]

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

--- Comment #7 from Stefan Majewsky  ---
(In reply to Ian Wadham from comment #6)
> @Matthew: I had a brief look at how Palapeli is handling selects. It is
> mostly home-grown and could be changed, but I won't be fixing it.  See my
> reply to Christoph.

Yeah, that was a result of my naive over-engineering back in the day. It was on
my laundry list to rip out that monstrosity and move to simple hard-coded mouse
actions, see e.g. [1]. I don't have had the time for quite a while to hack on
KDE (and if I had, i would push the KF5 port through first), but if anyone
wants to cleanup this mess, then by all means go ahead. And CC me on the review
request if you like some extra pair of eyes that's familiar with the codebase
(or at least was 4 years ago).

[1]
https://majewsky.wordpress.com/2012/02/13/is-anyone-using-custom-mouse-actions-in-palapeli/

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Ian Wadham via KDE Bugzilla]

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

--- Comment #6 from Ian Wadham  ---
@Matthew: I had a brief look at how Palapeli is handling selects. It is mostly
home-grown and could be changed, but I won't be fixing it.  See my reply to
Christoph.

QAbstractItemView is part of the model/view classes (lists, tables and trees).
I suppose it would apply to selections in the view of the puzzle collection (a
list view), but it does not apply to pieces on a puzzle table.

Do you wish to make the changes and commits to fix this bug? If so, I can help
you get started.

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Ian Wadham via KDE Bugzilla]

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

--- Comment #5 from Ian Wadham  ---
(In reply to Christoph Feck from comment #4)
> Ian, while Palapeli has a KF5 port lingering at the frameworks branch, the
> released version is still KDE4 based. So hack ahead ;)
Thanks, I know that, but I have retired from KDE programming, permanently.

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Christoph Feck via KDE Bugzilla]

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

Christoph Feck  changed:

   What|Removed |Added

 CC||cf...@kde.org

--- Comment #4 from Christoph Feck  ---
Ian, while Palapeli has a KF5 port lingering at the frameworks branch, the
released version is still KDE4 based. So hack ahead ;)

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Matthew Woehlke via KDE Bugzilla]

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

--- Comment #3 from Matthew Woehlke  ---
(In reply to Ian Wadham from comment #1)
> (In reply to Matthew Woehlke from comment #0)
> > Multi-select behavior should work like it does in every other application.
> 
> Is there a standard on this?  If so, Palapeli should follow it.

Certainly there is the way it works in QAbstractItemView and derived classes.
AFAIK this is consistent (most Qt applications at least are relying on this for
selection behavior, and I think also most of the major toolkits agree on this
selection behavior). Anyway, it makes sense to follow what QAbstractItemView
does.

Note of course I am talking about the ExtendedSelection mode, which seems to be
the most commonly used, at least for instances when you think about selecting
items (e.g. not systemsettings, configuration dialogs). Compare for example the
behavior in gwenview or dolphin.

(In reply to Ian Wadham from comment #2)
> I have not checked the code, but I am pretty sure this behavior is nothing
> to do with Qt or QGraphicsView.

Sure; looking over the documentation, it seems QGraphicsView has some helpers
for selecting things, but isn't primarily responsible for selection behavior.
Previously, I didn't know if it was or wasn't.

> There are some other mouse operations I am not happy about in Palapeli, such
> as the possibility of crashing Palapeli when dragging and joining pieces. 

Ah... yeah, noticed that too :-).

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Ian Wadham via KDE Bugzilla]

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

--- Comment #2 from Ian Wadham  ---
(In reply to Matthew Woehlke from comment #0)
> I'm not familiar enough with how palapeli is implemented, but it occurs to
> me the problem might be in the QGV frameworks? (In which case I'm happy to
> punt this to Qt...)

I have not checked the code, but I am pretty sure this behavior is nothing to
do
with Qt or QGraphicsView.

There are some other mouse operations I am not happy about in Palapeli, such
as the possibility of crashing Palapeli when dragging and joining pieces. 

Unfortunately I am not in a position to do any serious maintenance, due to my
advanced age and the fact that I am on an Apple computer and do not yet have
KF5.  I last worked on Palapeli about a year ago.

If you are interested in fixing Palapeli, I could help you find the pieces of
code
that need work and perhaps suggest some patches.

The position of maintainer is also vacant and porting to Frameworks is
incomplete.

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

[palapeli] [Bug 366796] Ctrl-click should never, ever deselect all pieces

[Ian Wadham via KDE Bugzilla]

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

Ian Wadham  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||iandw...@gmail.com
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Ian Wadham  ---
(In reply to Matthew Woehlke from comment #0)
> It is very, very frustrating when I am trying to select a bunch of pieces by
> clicking on them individually while holding ctrl that palapeli drops my
> entire selection if the mouse is over the wrong pixel when I click.
> 
I agree, but perhaps not with a second "very"... :-)  Also the procedures for
deselecting a whole group of selected pieces or just one piece from such a
group should be clearer and more intuitive.

> Multi-select behavior should work like it does in every other application.
> Specifically:
> 
> - A ctrl-click on empty space DOES NOTHING. It absolutely, positively should
> not deselect every piece I've worked hard to select.
> - A ctrl-click-and-drag should ADD to the selection, not replace it.
> 
Is there a standard on this?  If so, Palapeli should follow it.

> (It would also help if there was a little fudge factor for clicking on
> pieces, but that probably deserves a separate report.)
> 
Agreed, but the little hand that appears is a reliable indicator, even
for pieces that are currently too small to see properly.

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