Red Hat Bugzilla – Bug 131547
Evolution Cal does not allow mouse highlight
Last modified: 2014-03-25 20:50:59 EDT
Description of problem: In the Day and Work View of Evolution Cal, individual time entry cannot be hightlighted by mouse but in the Week and Month view, the problem does not exist. Version-Release number of selected component (if applicable): - evolution-data-server-0.0.97-2 - evolution-1.5.92.2-2 How reproducible: Always Steps to Reproduce: 1.Start Evolution Cal 2.Create an appointment 3.Click on the time slot of the appointment created (will see a blinking cursor) 4.Hightlight the entry with the mouse Actual results: Clicking the entry is fine but following that, the widget no longer accepts input form mouse. Expected results: Mouse able to hightlight an entry in the time slot. Additional info: Affects all locale including en_US
Filed bug upstream. http://bugzilla.ximian.com/show_bug.cgi?id=65436
To rephrase: In the Week and Month View of Evolution Cal, after selecting an appointment, you can select the text using mouse-down and drag (as expected) However in the Day and Work View, after selecting the apoointment, you can't highlight the text with mouse-down and drag (bug). (verified, with Evolution 2.1.3.1)
Still happening in evolution-2.2.1.1-2 and evolution-data-server-1.2.1-1
Does this still occur in rawhide?
Yes, I still saw this problem with evolution-2.3.7-1, e-d-s-1.3.7-1.
still happen in evolution-2.3.8-3 and e-d-s-1.3.8-4
Still happening in Evolution 2.7.1
COnfirmed with 2.7.4 Changing component to Evolution
With evolution-2.7.92, I can't seem to highlight text in _any_ of the views. So is this bug really about being able to highlight text in the Day and Work views, or is it about the inconsistent highlighting behavior. Because it seems consistent now, just not in the way we hoped for. Or is the current behavior a regression?
It might be possible that evo was designed to be this way... to not enable selection of text untill the event is double clicked & launched in a full fledged edit window.
Perhaps, but it sounds like it was at least partially working before, either by fluke or by design. Given that text highlighting no longer works in _any_ of the views (can someone confirm this, btw?), it seems to me this bug could be closed in one of two ways: 1) If the reporter was objecting to the inconsistent highlighting behavior, then this can be closed because the highlighting behavior is now consistent. 2) If the reporter was filing the bug because he wanted to be able to highlight text in any of the calendar views, then one could argue that this is now a feature request and the discussion should be taken upstream. Setting this to NEEDINFO to get Lawrence's thoughts, if he even remembers filing this one two years ago. :)
Tested with followin versio: evolution-2.8.0-1.fc6 Obervation: Day/Week/Month View, selection of text is not possible by mouse, only in List view you can.
As per a chat excerpt from irc.gnome.org """<makuchaku> Hi all, I'm looking at a bug report (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131547) which says that a user cannot select text from a calendar in day/week/month view. Was this designed to be like this or this is really a bug? It should be noted that text selection in possible in list-view. <makuchaku> If the calendar was designed with user-should-not-select-from-view concept in mind, then I can proceed to close this bug or else I can try fixing this. <kjetilho> makuchaku: if a user finds it useful and it doesn't break other bindings, I don't see why it shouldn't be fixed. <makuchaku> kjetilho: the user might have thought the same... also to be noted that user can select text from keyboard using shift+arrow-key combinations <makuchaku> hmm """
Also, I confirm that text cannot be selected from day/week/month views but can be selected from list-view.
Tested on evolution-2.9.1-2.fc7
Hi Matthew, I dont know if this could be of any help or not... Check "e_text_command" in $evo/widgets/text/e-text.c & see the case "case E_TEP_SELECT" This is just for the day view BTW :) Thanks, Mayank
Closing this as upstream as we have it there already.