| Summary: | The KMyMoney selector is not moved when the combo it belongs to is move together with the containing window | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | allan <agander93> |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | onet.cristian |
| Priority: | NOR | ||
| Version: | SVN | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
allan
2011-06-12 11:42:49 UTC
I've just noticed something very similar. If a new transaction is opened, and then the category selection drop-down is opened, while that is showing, the KMM window can be moved away, leaving the drop-down behind. Apart from the title bar and the status bar (Cleared...Balance), clicking anywhere else closes the drop-down. Editing an existing transaction shows the same effect. I've been working away on this for a while now and have fixed three problem areas - reassign category, import file selector and ledger view editing a category. I was beginning to think I'd finished, but then found that editing the category in a split had the same issue, and now I've just found that editing a schedule also shows the same issue. I don't know how many more areas will need attention. However, I'm beginning to think I'm tackling the symptoms rather that the cause. @ Thomas please. Obviously the common area is the category selector/completor, but I still seem to have to edit the code in the various dialogues/views event filters. Do you think the solution ought to be confined to the selector/completor areas? Along the way, I've learned more about this area and am beginning to wonder whether to throw it all away and start again from scratch. Part of the problem is that clicking on the title bar when attempting to move the window is not directly accessible within the application, without redesigning each dialogue/ view. So, I've been identifying when the cursor goes out of bounds, and hiding the selector/completor drop-down so that it doesn't get left behind on top of all other windows, which is obviously wrong. If you are unable to give an answer without having to go digging, I guess I have to plod on. Thanks. Partially answering my own question, the only way I can see for a fix to be confined to the category selector/completor is to detect when the cursor moves out of the drop-down and to hide the drop-down. This will avoid the 'floating' drop-down superimposing itself above all other windows, which is an annoyance. Requiring a mouse click first would require edits to all the calling functions/classes. I was unable to find a way to anchor the drop-down to the calling dialog/view. Will this suffice, do you think? My opinion is that it seems that we would need to do too much (based on the time you need to investigate this) for too little (I find this issue of a very low importance). On 16/03/14 09:48, Cristian Oneț wrote: > https://bugs.kde.org/show_bug.cgi?id=275455 > > Cristian Oneț <onet.cristian@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |onet.cristian@gmail.com > > --- Comment #4 from Cristian Oneț <onet.cristian@gmail.com> --- > My opinion is that it seems that we would need to do too much (based on the > time you need to investigate this) for too little (I find this issue of a very > low importance). > I agree with you that it is of low importance. When I started looking into it, I thought it would just need a simple fix, but it turns out otherwise.... But, are you saying do nothing, or do the minimum? (having got this far). Allan Confining changes to kmymoney/widgets/kmymoneycompletion requires about 40 lines, and that fixes all uses. What I've also done, already, is to fix a couple of UI dialog sizes to avoid the drop-down hiding several important buttons. This avoids the untidiness. Please decide what you would like to do about this. In my opinion we should leave it as is if we can't find an elegant solution. "to detect when the cursor moves out of the drop-down and to hide the drop-down" is not a solution, think about keyboard driven usage when the cursor is not even in the drop-down. (In reply to Cristian Oneț from comment #7) > Please decide what you would like to do about this. > > In my opinion we should leave it as is if we can't find an elegant solution. > > "to detect when the cursor moves out of the drop-down and to hide the > drop-down" is not a solution, think about keyboard driven usage when the > cursor is not even in the drop-down. I think just close it. |