After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777830 - (Year view) change navigator to use GtkFlowBox and GcalDateChooser widgets
(Year view) change navigator to use GtkFlowBox and GcalDateChooser widgets
Status: RESOLVED OBSOLETE
Product: gnome-calendar
Classification: Applications
Component: Views
unspecified
Other Linux
: Normal major
: 3.26
Assigned To: GNOME Calendar maintainers
GNOME Calendar maintainers
Depends on:
Blocks:
 
 
Reported: 2017-01-27 13:26 UTC by Georges Basile Stavracas Neto
Modified: 2017-11-24 22:09 UTC
See Also:
GNOME target: ---
GNOME version: 3.23/3.24



Description Georges Basile Stavracas Neto 2017-01-27 13:26:47 UTC
Rewrite the Year view to use the GtkFlowBox widget.
Comment 1 Georges Basile Stavracas Neto 2017-02-09 10:43:30 UTC
Some questions that were discussed on IRC.

1. Should months show the other months' days?

For now, let's just hide them. We can reconsider adding it again once things settle.

2. How to handle drag selection?

This will be a little complicated. The entire operation can be split in three phases:

 - Press: when the user just clicked somewhere in the widget
 - Motion whenever the user moves the pointer over the widget
 - Release: when the user unclicks a mouse button

Since this is a multi-widget thing, GcalDateChooser will have to communicate (i.e. send signals) to allow the parent widget to know what's happening. Notice that this is ~optional~! We don't want this behavior in the Edit dialog, so there should be API to enable/disable the button press/motion/release handling.

Lets think about each phase individually. I can picture the following solution on my mind.

i. Press: on button-press, GcalDateChooser stores the clicked date and send a ::selection-begin(GDateTime*) signal. Year view will respond to this signal resetting the _other_ datechoosers by setting the selection start (and setting the selection end to NULL). Something like this:

for (date choosers)
{
  gcal_date_chooser_set_selection_start (chooser[i], start); *
  gcal_date_chooser_set_selection_end (chooser[i], NULL); *
}

ii. Motion: with motion event, GcalDateChooser will send ::selection-end(GDateTime*) every time the hovered date changes.

iii. Release: button-release will send a final ::selection-end(GDateTime*) and we'll update the events on the sidebar.

Basically, GcalDateChooser will need a couple custom signals, and new selection-{start,end} fields, and API to set them.

* New API
Comment 2 nikhilnandyala97 2017-03-18 19:56:11 UTC
What would be the benifit of using gtkflowbox widget.What is bug that would be fixed or advantage of changing it from gtkgrid to gtkflowbox.
Comment 3 Georges Basile Stavracas Neto 2017-03-18 20:22:33 UTC
(In reply to nikhilnandyala97 from comment #2)

> What would be the benifit of using gtkflowbox widget.

GtkFlowBox, in a few words, is a better container for this task. We can achieve a more and adaptative interface using it.

> What is bug that would be fixed or advantage of changing it from gtkgrid to gtkflowbox.

The point is: we don't use GtkGrid now. Currently, it's just a giant GtkDrawingArea.
Comment 4 nikhilnandyala97 2017-04-01 17:26:48 UTC
Should I keep all the dates in every month as buttons or normal text. Could you elaborate the changes to be made .And about the other functionalities and whether it should look the same or not
Comment 5 nikhilnandyala97 2017-04-01 17:28:22 UTC
Should I keep all the dates in every month as buttons or normal text. Could you elaborate the changes to be made .And about the other functionalities and whether it should look the same or not
Comment 6 Georges Basile Stavracas Neto 2017-11-24 22:09:35 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calendar/issues/108.