Differentiate between "canceling" and "deleting"

[JadedCtrl]

This makes the distinction went over in #81— adds a seperate menu option for cancelling an event, changes the font-face of cancelled events, and moves deleted events to the trash (as opposed to keeping them in a "cancelled" folder forever).

Also made a change to the Event:Status file attribute, so on first run it'll have to migrate old values over ("Cancelled" no longer means "Deleted/Hidden", so: "Cancelled" -> "Deleted")— it worked on my system, but this should probably be tested by someone else.

[scottmc]

By "deleting" rather than canceling, you get a message making sure you want to send it to the Trash... clicking ok makes the event go away. But looking in the trash bin on the desktop I don't see any events sitting there. So if it is just truly deleted and not just put in the trash we should probably say that. Alternatively, maybe events could be files, like Haiku does with emails. Each one is a file and then can be handled by the file system.

[JadedCtrl]

Events are all files (kept in ~/config/settings/Calendar/events)― they should just be moved to trash on delete, no files are actually deleted. If files aren't moved to trash on your system, it might be a path issue? I'll make a patch tomorrow to print them (if you wouldn't might testing again to see).

[scottmc]

Tried it again. Deleted events are going to /boot/home/config/settings/Calendar/deleted and not Trash Maybe try using FindDirectoy looking for " B_TRASH_DIRECTORY"?

Lesson 20 of Programming with Haiku covers drag and drop support. It mentions the trash can and how you can drag things to it. Might be interesting to add that support in the future.

[JadedCtrl]

Oooh, I see the issue @scottmc. That's intended behavior if sync is configured ("sync" is in the config directory)— events are put into that folder instead, so that they can be handled in the next sync.

… But thinking about it some more, that's probably not a good distinction to make. I'll remove it.

Dragging-and-dropping events onto Tracker's a good idea, too. o

[JadedCtrl]

Alright, there is no "deletions" folder anymore― even if sync is configured, events go right in the trash. It makes more sense for removing events to be local anyway, it shouldn't affect events on the server (and if it should, the sync add-on should check for missing events itself).

[scottmc]

Getting closer. I was ok with keeping the cancel option along with the delete option. But delete option along is ok too. As long as there is a way to restore them. I just tried it and i am able to delete an event, and it shows up in the Trash as one would expect. However, right clicking it and selecting restore, does not make it show back up in Calendar. Perhaps that can be fixed in a future update here? Let me know if you want to have this one accepted before working on the restore part, or wait.

[JadedCtrl]

Thanks for testing― completely forgot restore was a thing, it should be working now. :)

[scottmc]

Nope. Now deleted items skip the Trash can, so there's nothing there to restore?

[JadedCtrl]

I don't understand― do deleted events not show up in Trash anymore? The only thing I changed was adding the "_trk/original_path" attribute. :o

[scottmc]

I'm still seeing strange behavior here. If I create two or more events on a given day, I can right click on one and delete it. It disappears. But doesn't ever show up in the Trash. If I then try to create a new event with the same name as the deleted event, i get an error message "There was some error in adding the event. Please try again." If I change the new event name to one that hasn't been used before it then works.
I pulled in these latest changes and rebuilt. I am using Haiku R1B3 gcc2 with setarch x86 Are you seeing this same issue or not?

[JadedCtrl]

I was able to replicate the error with creating an identical event to a trashed one (just addressed in push), but I can't with events not showing up in Trash.

This last push also prints paths whenever an event is being trashed, would you mind trying with that?

[scottmc]

Ok, was partially operator error here. I forgot to checkout the cancelation branch. I've done that with the latest commits and it is now deleteing and putting in the trash. I can select them in trash and "restore" then and they show back up in Calendar in italics which is think means it's been canceled? I then try to edit one of them and save and then all of the ones I restored disappear from Calendar and show back up in the Trash.

[JadedCtrl]

Thanks, I see the issue― you're migrating events from the old method of handling deletions/cancellations (deleted events used to be put into "cancelled"), which moves all events from "cancelled" into the Trash before removing the directory. This then lead to the restore path being "cancelled", so as soon as they'd be restored, Calendar would move them back into the Trash. :P

When migrating, the restore path is set to "events" now.

[scottmc]

Almost there. Canceling and deleting now work as I'd expect them to. Restoring also works, but when I restore something it doesn't appear back in Calendar until the view gets refreshed, either by clicking on a different day and then clicking back or someother such even that causes the view to refresh. See if you can make it fresh if/when an event is restored.

[JadedCtrl]

Yea, that is annoying. From what I can tell, that'd require using live queries, and with the way that Calendar's designed right now that'd take a lot of restructuring— either QueryDB would have to move to a message-sending model, or the QueryDB abstraction'd have to be removed.

I'd like to get to that at some point, but I think it's a bit out of scope for this one.