Either replace InventoryListener#onClose(InventoryCloseEvent)'s argument, or its implementations', with a proxy class named CloseableInventoryCloseEvent which wraps around a InventoryCloseEvent marked with Lombok's @Delegate annotation, then implement the Cancellable interface.
Another idea is for the CloseableInventoryCloseEvent to be an extension of InventoryCloseEvent and implementation of Cancellable. That would require a new [custom] event to be called.
Once the event arrives in a MenuManager and if isCancelled(), then re-open the inventory menu. This feature could be more intuitive for end users, though I'm not sure how it would be implemented and I think it would introduce a lot of checks and bugs. The main question is how to handle these custom events, their lifecycles, and avoid duplicate calls.
Either replace
InventoryListener#onClose(InventoryCloseEvent)'s argument, or its implementations', with a proxy class namedCloseableInventoryCloseEventwhich wraps around aInventoryCloseEventmarked with Lombok's@Delegateannotation, then implement theCancellableinterface.Another idea is for the
CloseableInventoryCloseEventto be an extension ofInventoryCloseEventand implementation ofCancellable. That would require a new [custom] event to be called.Once the event arrives in a
MenuManagerand ifisCancelled(), then re-open the inventory menu. This feature could be more intuitive for end users, though I'm not sure how it would be implemented and I think it would introduce a lot of checks and bugs. The main question is how to handle these custom events, their lifecycles, and avoid duplicate calls.