It would be nice if you could click the legends to show or hide the events with the same color as the legend. A checkbox could be placed in front of the legends to indicate the current visibility status:

In the backend we could provide a setting to toggle this on and off, this should default to off to not impact current implementations:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pfrenssen’s picture

Status: Active » Needs review
FileSize
8.2 KB
pfrenssen’s picture

Fixed firefox compatibility.

Interdiff:

       // Toggle event visibility and checkbox state when clicking on a legend.
-      $('.fullcalendar-legend .fc-event-default', context).click(function () {
+      $('.fullcalendar-legend .fc-event-default', context).click(function(event) {
         event.preventDefault();
pfrenssen’s picture

This needs work:

  • Legends using the default color can not be hidden since these do not have a colors-bundle-id class.
  • Remove dependency on Colors module.
  • Move the call to drupal_add_js() to fullcalendar_legend_build_legend() to avoid duplicated code.
  • Error when using default colors for taxonomy terms:

    Uncaught TypeError: Cannot read property '0' of null on fullcalendar_legend.js line 48

pfrenssen’s picture

Status: Needs review » Needs work

Looking further into this. It is not a good idea to remove the dependency on the Colors module, since this is doing exactly the thing we need: putting classes on every event, and it already supports different entity types. To only way to make this work without the Colors module is to duplicate much of its functionality. Instead it would be better to require the Colors module for this particular feature.

There is a snag though: the Colors module only adds classes to legends for which the colors are enabled. This makes FullCalendar Legend not useful at all for bundles that have their Colors support disabled as they will be all shown in the same default blue color. I'll file a separate issue for this.

pfrenssen’s picture

wickwood’s picture

Thank you pfrenssen for the work you are doing on this feature! This is exactly what I need!

I'm always amazed how often when I need some feature in a Drupal module, coincidentally someone much more capable than me has just started working on it.

I will try out your patch and give you any feedback and help that I can.

Steve

pfrenssen’s picture

Thanks, all help is much appreciated! I will continue working on this in a few weeks.

wickwood’s picture

This patch seems to be working just fine for me.

I only wonder if it's possible to still have the link go to the view of teasers and let the checkbox control the display of events on the calendar. Do you think that is possible?

Alternatively, and this might be the better option, to add a "list" button on the calendar itself. So the button options would be: Month, Week, Day, List. Where list would should a view of any events selected in the legend.

Thanks again for the all your work on this pfrenssen.

Steve

FreekyMage’s picture

I've taken over this project from pfrenssen.

There was 1 bug with the patch when a term did not have a color setting. While fixing that I also did some small changes, including getting rid of the checkboxes because we did not need them. If the checkboxes need to be added again, I can always to that, but for me and for this project this way seems more logical.

The patch I created is a patch on his patch, sorry about that, I don't have time atm to create a standalone patch.

FreekyMage’s picture

The client asked for some more functionality where the events would be filtered depending on the url. The site has a url like "/term-name/page-name" because everything is based around the terms. Because of that the patch is not really usefull for this project in general, but some people might find it handy so I decided to post it anyway.

I also added a cache in Drupal.fullcalendarLegend.update()

pfrenssen’s picture

Can you please keep the scope of this issue to "showing and hiding events by clicking on the legends" and not post unrelated patches? This confuses the issue and prevents people from working on it.

If you want to have filtering on the URL, then please open a new issue.

FreekyMage’s picture

I know that, but the patch is applied to a file that is created in this issue.

kristiaanvandeneynde’s picture

I've created a patch incorporating #9 and #10, including a proper interdiff.
I'll try to weed out what belongs in this issue and what doesn't.

There was another patch used in the project that wasn't posted to drupal.org.
I'll see if it somehow relates to this issue as well.

kristiaanvandeneynde’s picture

Okay, so basically #9 is a valid patch although the checkbox removal can be contested. For the project Freekymage speaks of, it was a valid choice, but that should not affect this issue.

Patch #10 is almost completely unrelated, except for the cached variable.

The extra patch I spoke of in #13 is actually a fix for #1393722: Allow selecting a specific vocabulary for FullCalendar Legend. I'll see if I can clean it up and post it there when I have the time.

What a mess this has become :/

kristiaanvandeneynde’s picture

Status: Needs work » Needs review
FileSize
6.35 KB

Okay, so I've completely reworked the JavaScript part to be more lightweight. It only acts on page load or label clicks now, not AJAX calls. It doesn't add a checkbox, however.

I figured adding the 'fc-event'hidden' class allows for themers to do what they want with the labels' enabled and disabled state. You can then set labels to hidden by default by simply adding the 'fc-event-hidden' class to them in an alter hook.

milos.kroulik’s picture

I test the patch in #15 and can confirm, that it works. I will test the theming part and if everything goes well, I think we could mark this as RTBC.

kristiaanvandeneynde: Would it be difficult for you to add the checkboxes again? Thanks a lot!

kristiaanvandeneynde’s picture

I could add them again, but that would merely add a form element to the DOM that does nothing. Especially when it comes to checkboxes (which are hard to style cross-browser), this is not the best solution.

Instead, you could theme 'nice' checkboxes and use them as a background-image for the filters, making them 'checked' or not depending on the classes applied to the filter (fc-event-hidden).

Out of the box it would no longer show checkboxes, but when themed it would be much more flexible.

milos.kroulik’s picture

Thanks for clarification. I respect your point of view, but I read multiple times, that it's in fact OK to not style form elements, because users can recognize their native appearance easily (which is more important than niceness). Also, I believe there there is another important reason for checkboxes - they allow us to unify the look of Fullcalendar legend with Views exposed filter block, styled with Better expose filters.

So, can we have a choice? Of course I understand, that you're not interested in something you won't use personally.

kristiaanvandeneynde’s picture

It's not that I'm not interested, it's more of a twofold issue:

  • Currently the elements are all manipulated through JavaScript, adding checkboxes in a way that other modules could interact with them would require to do it through PHP.
  • I'm very busy on both client projects and my own module, if it isn't a bug fix or a feature I need myself, I cannot spend too much time on it sadly :(
kkasischke’s picture

Cross posted from Allow selecting a specific vocabulary for FullCalendar Legend.

I applied the patch from #15, and then the patch from this issue, Allow selecting a specific vocabulary for FullCalendar Legend - #8. Now, no matter which term I click in the legend, all the events toggle between hidden/shown, instead of just the ones with the appropriate terms. Has anyone else observed this? Not sure where to go from here.

kristiaanvandeneynde’s picture

Do you use the Colors module integration? The JavaScript relies on it as explained in #3. I basically rewrote and cleaned up the JavaScript without changing much of its core functionality.

kkasischke’s picture

That was the step I was missing! Thanks. I had it enabled at one point, but then the client didn't need different colors, so I turned it off. Once I enables the colors modules, everything worked again as it should. thank you for your work on this.

JKingsnorth’s picture

Issue summary: View changes

I can confirm that the patch in #15 is working fine, but I have two suggestions:

1 - I agree that checkboxes would be a good idea, for consistency with other views exposed filters. Designers can always remove the checkboxes through CSS if they don't want them to display, using the classes you have implemented to add additional styling (or use both!)

2 - From a usability perspective, from the default 'all showing' display, I would have expected clicking on a legend item to display only events in that category. Currently the first click on a term removes that item from the display - the opposite to what I would expect to happen. Perhaps the first click could narrow down the filter, displaying only the option clicked?

kkasischke’s picture

I agree with .John about the usability issue. I stopped using this functionality due to complaints, and replaced it with links to separate pages with views of events with that taxonomy term. Clunkier behavior, but much less confusing.

pfrenssen’s picture

FileSize
23.67 KB
23.19 KB

If this is confusing then you probably need to provide some better visual cues through theming. This is following a very common pattern: all options are on by default and can be disabled by clicking.

Here is a good example of how this can be made very clear through theming (taken from Drupical):

By default all options are visible:

Click on an option to disable it:

SocialNicheGuru’s picture

Right now I choose taxonomy and select my vocab.
When I click on the term I am taken to the term page.
It gives me a list of the items with the term.

But I am not kept on my calendar page with the filtered events.

is that the way it is supposed to work?

mastoll’s picture

@pfrensen, as of 10/30/15, the Drupical site no longer uses the "click to disable" option. That page loads with all enabled, then clicking a single item disables every option but the one clicked. Thus, it is now using a "click to ENable" strategy.

From the site's changelog:
"Improve usability of event type filter
The icons (which are technical just checkboxes) now behave differently if all are checked, in this case a click on one will only select that."

How can we accomplish this improved usability behavior i.e. the first click on the page disables all menu items then re-enables the one clicked, setting up the click-to-enable strategy?