GNOME Bugzilla – Bug 516943
Disable direct event Summary edit by default
Last modified: 2018-04-11 18:41:46 UTC
currently, the appointments in the calendar have terrible usability because you have to double or triple click very fast, precisely, and the results are often unpredictable (ie: nothing happens even if you click ten times, or an event's text is selected at best) or undesirable (the appointment editing window shows up, but in the background due to metacity detecting a click or two just before it is created). Needless to say, this situation sucks horribly, especially since you can't move events by drag and drop (bug #328633). There are two simple workarounds to this situation (because, really, the user should not even have to double click here): - use single click. If the user clicks any appointment and that click is not a drag event, bring up the appointment editing window. - show an "edit" button in the toolbar (suboptimal).
i've never had any problems with it... what distro is this? which view?
I would guess it affects any distro (seen this for years on ubuntu, I don't remember on fedora), and it is on any view. Month view, week view. I'll shoot a small video showing the problem if I can.
Created attachment 105433 [details] brief video showing the problem (zoomed in screen for legibility) see also this longer video [1] (a screencast) with my narration and hypotheses of the problem; however in the video the mouse cursor does not show up exactly where it was in reality (I swear, I was clicking *inside* the appointments! :) For example, at 1:45, the tip of my cursor's arrow really did click precisely where the blinking text cursor was. [1]: http://jeff.ecchi.ca/public/evolution-bug-516943-2.ogg
Bumping version to a stable release.
I think I figured out part of the problem: you have to have the event already selected (1 click) before trying to double-click it to edit it. If the event is already selected, double-clicking pretty much always works. However, it should not be so. I should not have to triple-click-with-a-high-rate-of-failure if the event is not selected. Do you have a better idea of the cause behind this problem now? I think I somewhat understand why it's that way, but I can't really explain/describe it. Having an "Edit" button in the toolbar would help alleviate this issue, too.
Ok, the "edit directly in the calendar canvas view" thing is utterly broken. It even messes up and causes crap like Bug #578764. Could it please be thrown away and just replace this by "single clicking a calendar event opens the event properties dialog"? It would make everything much simpler and easier to use.
I suggest a new solution to this issue: Disable the "rename calendar event on single click" feature. Instead, when clicking on an event, open the edit dialog. Rationale: Editing calendar events is quite hard to do right now because even if you want to change e.g. date or time, you often end up editing the name. This would also fix bug #537048.
*** Bug 794517 has been marked as a duplicate of this bug. ***
Thanks for a bug report. While I disagree with "edit on single click", you really do not do that in the List view, why to do it in the other views, then I agree to add an option to not edit event summary "inline".
Created commit 7a36dabc7f in evo master (3.29.1+)
> While I disagree with "edit on single click", > you really do not do that in the List view, > why to do it in the other views, If you're comparing the calendar's cell views to the mailer's listview, you're comparing apples and oranges. The reason why the listview can afford to not enforce single click release is because it has a "preview pane" sidebar (which is read-only anyway). The calendar view doesn't have such a sidepane, let alone one where you can edit the event. > add an option to not edit event summary "inline". I would say no option, just disable the (buggy and not very discoverable) inline editing of events and let people open the event to edit it, like in every other calendaring application I've seen... and it'll simplify your code.
(In reply to Jean-François Fortin Tam from comment #11) > If you're comparing the calendar's cell views to the mailer's listview, No, I do not. I've been talking about calendar's List View and specifically single-clicks. > I would say no option, just disable the ..... Too late, this bug is closed, the change is in the code (comment #10).
Ah, the calendar's listview, I had forgot this even existed :) indeed I see it allows editing directly within the listview too, and that seemed similarly unnecessary (vs double-clicking to open and edit the event); I still don't think an option for this would be necessary, IMHO it is kind of expected that to edit the properties of an event you double-click to edit it. I was simply making a recommendation here on what I think would be better architecturally (remove dead code, less technical debt and smaller testing matrix) and in terms of user experience (saner behavior by default). i.e. to make your job easier instead of piling even more stuff on top; but at the end of the day you make the decision as a maintainer and I'm not going to press further.