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

Allow tasks list to use full width #2165

New Issue
Open
opened 2026-03-22 13:56:48 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-03-22 13:56:48 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).

Original issue by Bouni on 2023-04-05T06:17:23.000Z

Version information:

Frontend Version: 0.20.5
API Version: v0.20.4
Browser and OS Version: Firefox 111.0.1 (64-Bit) / Windows 11

Question / Feature request

I wonder why the list view is limited to 1024px where the other layouts (Gant, Table) use the full width?
Is that by intention?

I would really like to use the entire with of my screen because some elements are hidden due to the limited size.

grafik

Original issue on Gitea

@kolaente commented on 2023-04-05T06:53:26.000Z:

I think I never questioned the width of that view. It's always been like that.

If we would just make it wider, not sure if that would look nice all the time. I guess let's try it?

@kolaente commented on 2023-04-05T06:55:55.000Z:

This doesn't look too bad:

image

I think on an ultrawide screen it's too much though:

image

Maybe we could just increase that 1024px max-width to something like 1500?

Bouni commented on 2023-04-05T07:16:17.000Z:

I did a test and 1800px looks better for me on a 2560x1440 screen 😄

grafik

What about a percentage or something like 70vw?

I'm far from experienced with CSS so don't hesitate to use whatever units seems best for you!

Edit: is there a breakpoint to determine if we are on a ultrawide screen? If so I would opt for 100% width below ultra wide and something else on ultrawide ...

@kolaente commented on 2023-04-05T07:18:15.000Z:

What about a percentage or something like 70vw?

That might work, but IMHO we should make that the minimum then and keep the 1024px. So that it always takes up 70vw, unless the screen is smaller than 1024px. In that case it should be 100%.

@kolaente commented on 2023-04-05T07:19:18.000Z:

Edit: is there a breakpoint to determine if we are on a ultrawide screen? If so I would opt for 100% width below ultra wide and something else on ultrawide ...

I think there is one called $fullhd at 1344px.

dpschen commented on 2023-04-05T08:59:19.000Z:

Define the max-width as 70ch. That's about the upper limit of the optimal reading line length. If there is more text we should wrap instead.

Regarding full-with: If we do that it should be a toggleable view setting.

EDIT
With the 70ch I meant the width of the text inside the item, not the line wrapper.

dpschen commented on 2023-04-05T09:01:57.000Z:

I did a test and 1800px looks better for me on a 2560x1440 screen 😄

grafik

When I saw that I had to immediately think if it wouldn't be better to wrap the meta info per task in a second line instead.

dpschen commented on 2023-04-05T09:03:56.000Z:

Is that by intention?

It's limited by intend. As written we should definitely wrap the text though. I also agree that even wirh the text or meta wrapping it might also profit from a a bit larger max-width.

Bouni commented on 2023-04-05T10:00:08.000Z:

@dpschen

Regarding full-with: If we do that it should be a toggleable view setting.

That would be absolutely perfect if a user could just enable that via the settings!

But also extend from 1024px to 70vw and additionally having meta info in a second line would be super even if full width is disabled!

Bouni commented on 2023-04-05T10:03:20.000Z:

One more thing (not sure if that should go into a separate issue), I juts noticed that the assigned user icons are spaced quite far from each other in the list view:

grafik

But in the details of that task they are semi-stacked:

grafik

The stacked version is in my opinion what should be used in the list view as well. Maybe thats a bug!?

@kolaente commented on 2023-04-05T11:17:38.000Z:

The stacked version is in my opinion what should be used in the list view as well.

I'd say that's a bug. As you pointed out, they should be stacked in the list view as well. Opened an issue from your comment: https://kolaente.dev/vikunja/frontend/issues/3354

Bouni commented on 2023-12-01T13:30:37.000Z:

@dpschen any news on the toggleable view setting or line wrapping?

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). _Original issue by Bouni on 2023-04-05T06:17:23.000Z_ <!-- Please fill out this issue template to report a bug. If you want to propose a new feature, please open a discussion thread in the forum: https://community.vikunja.io --> **Version information:** Frontend Version: 0.20.5 API Version: v0.20.4 Browser and OS Version: Firefox 111.0.1 (64-Bit) / Windows 11 **Question / Feature request** I wonder why the list view is limited to 1024px where the other layouts (Gant, Table) use the full width? Is that by intention? I would really like to use the entire with of my screen because some elements are hidden due to the limited size. ![grafik](/attachments/36ff4bc1-71c5-4441-8c8c-10c76882f5ea) [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/2041) --- _**@kolaente** commented on 2023-04-05T06:53:26.000Z_: I think I never questioned the width of that view. It's always been like that. If we would just make it wider, not sure if that would look nice all the time. I guess let's try it? --- _**@kolaente** commented on 2023-04-05T06:55:55.000Z_: This doesn't look too bad: ![image](/attachments/cfad9bff-a56c-4349-aa2a-c618f9d37136) I think on an ultrawide screen it's too much though: ![image](/attachments/c4b537cd-68b4-4cb7-b8f9-49b18d2fc8c6) Maybe we could just increase that 1024px max-width to something like 1500? --- _**Bouni** commented on 2023-04-05T07:16:17.000Z_: I did a test and 1800px looks better for me on a 2560x1440 screen 😄 ![grafik](/attachments/7664adf1-f07f-4539-9cfd-cd23442082f0) What about a percentage or something like `70vw`? I'm far from experienced with CSS so don't hesitate to use whatever units seems best for you! Edit: is there a breakpoint to determine if we are on a ultrawide screen? If so I would opt for 100% width below ultra wide and something else on ultrawide ... --- _**@kolaente** commented on 2023-04-05T07:18:15.000Z_: > What about a percentage or something like 70vw? That might work, but IMHO we should make that the minimum then and keep the 1024px. So that it always takes up 70vw, unless the screen is smaller than 1024px. In that case it should be 100%. --- _**@kolaente** commented on 2023-04-05T07:19:18.000Z_: > Edit: is there a breakpoint to determine if we are on a ultrawide screen? If so I would opt for 100% width below ultra wide and something else on ultrawide ... I think there is one called `$fullhd` at 1344px. --- _**dpschen** commented on 2023-04-05T08:59:19.000Z_: Define the max-width as 70ch. That's about the upper limit of the optimal reading line length. If there is more text we should wrap instead. Regarding full-with: If we do that it should be a toggleable view setting. **EDIT** With the 70ch I meant the width of the text inside the item, not the line wrapper. --- _**dpschen** commented on 2023-04-05T09:01:57.000Z_: > I did a test and 1800px looks better for me on a 2560x1440 screen 😄 > > ![grafik](/attachments/7664adf1-f07f-4539-9cfd-cd23442082f0) When I saw that I had to immediately think if it wouldn't be better to wrap the meta info per task in a second line instead. --- _**dpschen** commented on 2023-04-05T09:03:56.000Z_: > Is that by intention? It's limited by intend. As written we should definitely wrap the text though. I also agree that even wirh the text or meta wrapping it might also profit from a a bit larger max-width. --- _**Bouni** commented on 2023-04-05T10:00:08.000Z_: @dpschen > Regarding full-with: If we do that it should be a toggleable view setting. That would be absolutely perfect if a user could just enable that via the settings! But also extend from 1024px to 70vw and additionally having meta info in a second line would be super even if full width is disabled! --- _**Bouni** commented on 2023-04-05T10:03:20.000Z_: One more thing (not sure if that should go into a separate issue), I juts noticed that the assigned user icons are spaced quite far from each other in the list view: ![grafik](/attachments/4fcebeae-cf6b-47ef-a745-71c509b5111f) But in the details of that task they are semi-stacked: ![grafik](/attachments/4608f33c-5619-487b-958c-77037f01eec1) The stacked version is in my opinion what should be used in the list view as well. Maybe thats a bug!? --- _**@kolaente** commented on 2023-04-05T11:17:38.000Z_: > The stacked version is in my opinion what should be used in the list view as well. I'd say that's a bug. As you pointed out, they should be stacked in the list view as well. Opened an issue from your comment: https://kolaente.dev/vikunja/frontend/issues/3354 --- _**Bouni** commented on 2023-12-01T13:30:37.000Z_: @dpschen any news on the toggleable view setting or line wrapping?
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
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#2165
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?