github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-05 19:18:16 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[GH-ISSUE #497] Separate dialogs from popovers #6190

New Issue
Open
opened 2026-04-20 16:47:35 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-20 16:47:35 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/497

Original issue by dpschen on 2021-11-08T14:59:27.000Z

We should separate these usecase:

  • popover (former modal; popover is the better naming, also allows better distinction from 'model') is used for pages, basically an overlay with a UIs.
    popovers usually have a url

  • dialog: asking the user a question. e.g. delete.
    Not sure what to do with modals that had an url but would then loose it. But this also isn't consequent right now: some delete modals have a url others don't.

Popovers should not be stacked (although we might have some exceptions).
Dialogs might be stacked, but this is also discouraged. Better would be to create a user flow where this is not needed.

See also:
https://kolaente.dev/vikunja/frontend/pulls/816#issuecomment-16745

Original issue on Gitea

@kolaente commented on 2021-11-09T22:50:29.000Z:

I like the idea.

some delete modals have a url others don't.

That sounds like it should be more consistent.

Did you check which modals have a url and which don't? My guess is all modals which are accessible from the menu directly have one while the ones from a detail page don't.

dpschen commented on 2021-11-11T01:45:24.000Z:

I didn't check, but that might be!
Either way still not sure which way to go here: I like that there is a direct url for e.g. editing stuff. For deleting it doesn't make so much sense, since you shouldn't be able to navigate back to a delete dialog after you pressed delete.

dpschen commented on 2021-11-19T17:23:15.000Z:

Because of https://kolaente.dev/vikunja/frontend/issues/1037

I started implementing dialogs based on https://headlessui.dev/vue/dialog but with a promise interface.
Still iterating on that idea.

@konrad: what do you think in general?

@kolaente commented on 2021-11-22T18:35:53.000Z:

If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)?

In general, I think we could move forward with it.

dpschen commented on 2021-11-22T20:06:56.000Z:

If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)?

Yes they implement a lot of heavy to implement accessability stuff in there.

dpschen commented on 2021-11-22T20:07:26.000Z:

I started with this already, but still in an early phase.

dpschen commented on 2021-11-27T13:21:09.000Z:

I realized that the dialogs should probably be implemented in a way that you cann them via a function that returns a promise.

Does that make sense?

dpschen commented on 2022-05-20T16:35:03.000Z:

To remember for later: https://github.com/rlemaigre/vue3-promise-dialog

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/497 _Original issue by dpschen on 2021-11-08T14:59:27.000Z_ We should separate these usecase: - popover (former modal; popover is the better naming, also allows better distinction from 'model') is used for pages, basically an overlay with a UIs. popovers usually have a url - dialog: asking the user a question. e.g. delete. Not sure what to do with modals that had an url but would then loose it. But this also isn't consequent right now: some delete modals have a url others don't. Popovers should not be stacked (although we might have some exceptions). Dialogs might be stacked, but this is also discouraged. Better would be to create a user flow where this is not needed. See also: https://kolaente.dev/vikunja/frontend/pulls/816#issuecomment-16745 [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/1854) --- _**@kolaente** commented on 2021-11-09T22:50:29.000Z_: I like the idea. > some delete modals have a url others don't. That sounds like it should be more consistent. Did you check which modals have a url and which don't? My guess is all modals which are accessible from the menu directly have one while the ones from a detail page don't. --- _**dpschen** commented on 2021-11-11T01:45:24.000Z_: I didn't check, but that might be! Either way still not sure which way to go here: I like that there is a direct url for e.g. editing stuff. For deleting it doesn't make so much sense, since you shouldn't be able to navigate back to a delete dialog after you pressed delete. --- _**dpschen** commented on 2021-11-19T17:23:15.000Z_: Because of https://kolaente.dev/vikunja/frontend/issues/1037 I started implementing dialogs based on https://headlessui.dev/vue/dialog but with a promise interface. Still iterating on that idea. @konrad: what do you think in general? --- _**@kolaente** commented on 2021-11-22T18:35:53.000Z_: If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)? In general, I think we could move forward with it. --- _**dpschen** commented on 2021-11-22T20:06:56.000Z_: > If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)? Yes they implement a lot of heavy to implement accessability stuff in there. --- _**dpschen** commented on 2021-11-22T20:07:26.000Z_: I started with this already, but still in an early phase. --- _**dpschen** commented on 2021-11-27T13:21:09.000Z_: I realized that the dialogs should probably be implemented in a way that you cann them via a function that returns a promise. Does that make sense? --- _**dpschen** commented on 2022-05-20T16:35:03.000Z_: To remember for later: https://github.com/rlemaigre/vue3-promise-dialog
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label area/frontend area/internal-code concern/accessibility concern/ux
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#6190
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?