Added
- Organize events in several local calendars (#1243, from D#1231). Create and rename household
calendars, reorder them through the manager's More menu, choose the destination when importing an ICS
file, and share a separate ICS subscription link for each calendar. Calendar links include only events
visible to everyone in the household. Legacy iCloud auto-upload continues for the default calendar,
including when explicitly selected; events in other local calendars stay local. Deleting a calendar
moves its events to the default calendar, so with the legacy Apple Calendar connection they then
upload to iCloud; the delete confirmation says so when that connection is set up. - Checked-off shopping items collect in one section at the end of the list (#1816, from D#1624).
Ticking an item moves it out of its category into "Checked off", a collapsed section at the
bottom that shows how many items it holds. The items stay on the list, and the list above gets
shorter as you shop. Nothing moves while you are still ticking: the rows wait until you pause
for a moment and then move together. Whether the section is open is remembered per person and
per list. Adding a name that is checked off on the open list - picked from the suggestions or
typed - brings that row back instead of adding a second one, and a short note says so; an
amount you typed replaces the row's, an empty field keeps it. A name that is not checked off
on the list is added as before. - Dutch date format DD-MM-YYYY (#1847). The new
DD-MM-YYYYchoice is in Settings → Account →
Appearance → Date format, and the Netherlands region now uses it instead ofDD.MM.YYYY.
Dates, the date field placeholder, short dates and typed input all follow it. Existing households
keep the format they have set. A household that already has the Netherlands as its region gets
the new format by setting "Region" to "Custom" and then "Preferred date format" toDD-MM-YYYY. - Wall mode names today's tasks under each person (#1817, from D#1604). "Who's up today"
used to show a face and a number. It now lists each person's open tasks for today by title, and
below them, dimmed and with a checkmark, what they have already done today - so a glance shows
what is left and what is finished. The wall still does not scroll: it shows as many lines as
the screen has room for and says "+2 more" for the rest. When space runs short, finished tasks
give way first. Someone who has finished everything keeps their ticked tasks until the next
day. Only tasks the whole household may see appear; a task set to "Assignees only" is not on
the wall, whoever is signed in on the device. - A profile picture can be fetched from Gravatar once, if the operator turns it on. Off by
default: whileGRAVATAR_BASE_URLis unset or empty nothing is sent and Settings → Account shows
no button. An operator opts in by setting it tohttps://gravatar.com/avatar/or a Libravatar
mirror; a household member can then fetch the picture for their saved address, named in the
hint, and it is stored exactly like an upload, never fetched again. Split-expense guests are
refused. Only a SHA-256 hash of the address and the server's IP leave the server, through the
SSRF-guarded client with an 8 second limit, a 512 KiB cap and a signature check. If the
picture, the address or the account changes while the fetch runs, nothing is stored (409).
The hint and the error messages name the service the operator chose by its host name, so a
mirror is never called gravatar.com, and a failed fetch is announced once, in the form's error
line. - Tapping a category or subcategory in the budget overview filters the transactions list.
(#1593, from D#1583) The filter applies in place and can be cleared again. A category with
both income and spending is marked in both blocks, because the list then shows both; keyboard
focus stays on the bar that was tapped and its ring is no longer cut off, and whether the tap
jumps to the list follows the width of the budget area, not of the window. The bars answer to
the pointer. - The screensaver can show the time and fill the screen, chosen on each device (#1766, from
D#885). Two switches under Settings → Account → Appearance, below the delay: the current time,
on unless switched off, in the household's time format and zone, turning on the full minute and
sitting in the corner opposite the photo caption, moving with it so no text stays in one place;
and photos that fill the whole screen instead of fitting inside it, off unless chosen, because it
crops portrait photos. Both are stored in the browser like wall mode and the delay, so the frame
in the hallway and the kitchen tablet decide for themselves, and both apply from the next start
of the screensaver without a reload. - Tasks can be put in an order of your own within a category. In the task list grouped by
category, every row has a grip: drag it, or press the arrow keys at the focused grip, and the
order is saved for the whole household. Tasks you never placed keep the old order (due date,
then priority) and sort after the placed ones, so a new task lands at the end of its category.
A recurring task passes its place on to its next occurrence; a task that moves to another
category loses its place. A "Sort automatically" button in the group header returns a category
to the automatic order. Grouping by due date, the board, selection mode,tasks: readand the
wall display are unchanged. The API getsPATCH /api/v1/tasks/reorderand
POST /api/v1/tasks/reorder/reset, andsort_orderon each task (migration 242). - Custom modules can be installed from Settings, from GitHub or as a ZIP file, where the operator
allows it. Until now a third-party module reached Yuvomi only as a folder copied intomodules/
on the server. The new page Settings → Modules → Add custom module (admin only) takes the address
of a public GitHub repository or an uploaded.zipand installs the module from it. The feature
is off unless the operator setsMODULES_ALLOW_WEB_INSTALL: a module is JavaScript that runs
with the session of every member who opens it, so installing one is the operator's choice. A
module installed this way arrives disabled until an admin approves it in Active modules from a
browser session, and the web interface removes or replaces only what it installed. Limits, checks
and the API are inMODULES.mdunder "Installing From Settings". - Move a shopping item to another list (#1700, from D#998). The edit dialog has a list
selector under amount and category when there is more than one list. The item moves as it is -
name, amount, category, note, link, price and shop - and lands at the end of its category on
the other list, so nothing has to be typed again. Between two lists mirrored from a CalDAV
server the entry itself moves: Yuvomi reads it in the old list, stores it unchanged in the new
one and only then removes it from the old one, so its tags, alarms and everything another app
keeps on it come along - also from one account to another. If the server does not accept it
in the new list, the entry stays untouched where it was, and after the fifth refusal the item
is back on the list it came from, with a line in the sync log. The same happens when the new
list no longer exists on the server. While the new list is switched off in the reminder sync,
the move waits until it is switched on again. Moving an item to a
list that is not mirrored removes it on the server without deleting it in Yuvomi.
PATCH /api/v1/shopping/items/:itemIdtakeslist_idfor the same move (migration 243). - Wall mode: a button in the footer starts the photo screensaver by hand (#1766). When
Immich is connected, a picture symbol sits in the wall footer next to the exit button. Tapping
it starts the screensaver at once, the same as the idle timer would. The button shows the
symbol only and carries its name, "Screensaver", as a tooltip and for screen readers, so it
takes the same room in every language and does not push the timer buttons aside. While a
kitchen timer is running the button is not there: a photo covering the countdown is not a
timer. If the screensaver cannot start (no photos configured, Immich unreachable, or a
connection error), the button answers with one line instead. For a paired display the button
appears only when an administrator has switched the photo screensaver on for it under
Settings → Household → Wall tablets.
Changed
- Recipes mirrored from a Norwegian Mealie or Tandoor sort into shopping categories. The
keyword list that guesses a category from an ingredient's name now knows Norwegian words as
well as German and English, so "hvetemel" lands under baked goods and "oppvaskmiddel" under
household instead of everything ending up under "Other". Matching stays whole-word, so a
compound such as "kyllinglår" still falls through unless it is listed on its own. - The wall shows only what the whole household may see (#1817). Wall mode is a shared
surface, not a personal screen: it hangs in the kitchen, whoever opened it. The day's
programme and "Who's up today" now leave out every task and appointment that is not visible
to everyone - a task set to "Assignees only" or private, an appointment set to "Assignees
only" or private, and appointments from a calendar subscription that is not shared with the
household - also when the wall was opened from the session of the person they belong to.
Someone who would only be "up today" because of such an entry is not listed. The same holds
for what concerns one person alone: a wall opened from a member's session no longer shows
that person's medication doses, own shift, due reminders or the reward requests waiting for
their approval - a coupled display never showed them, and now every wall reads the same.
And the device on the wall no longer receives what the wall never draws: pinned notes, the
budget, shared-expense balances, quick links, countdowns and the housekeeper's unpaid amount
used to travel along in the background and now stay off it, as does anything a future module
adds until it is given a place on the wall.
The normal overview and "Today at a glance" stay personal and show all of it as before.
Fixed
- A photo screensaver started with the mouse stays open (#1766). Started from the wall footer
or as the preview in the Immich settings, it closed again as soon as the mouse left the button,
if the pointer had rested on it for more than a second before the click. While the photos were
still loading, that same move cancelled the start and the app said the screensaver was not
available. Moving the mouse now leaves it alone while the photos load and for the first second
after it appears; after that a move closes it as before. A key, a click, a touch or the wheel
close it at once, and the screensaver that starts by itself is unchanged. - Sign-in and setup: a form you are filling in is no longer cleared after a few minutes (#1919).
The photo screensaver started its idle timer on every page, also where nobody is signed in. Once
the idle delay had passed it asked for its photos, was refused, and the app took that for an
expired session and drew the sign-in page again - over whatever had been typed so far. The
screensaver now waits for somebody to be signed in, or for a paired wall display, and stops when
you sign out. After signing in it is ready without a reload. - Waste: an address that stops serving its calendar no longer wipes your pickups (#1938). A
subscribed waste calendar is fetched on its own. When the other side answered with something
that holds no calendar entry - a maintenance or login page, an empty calendar - Yuvomi took
that for a calendar with zero pickups: every imported pickup of the source was removed, the
reminders for them went with it, and the source looked healthy. Now such an answer is a failed
fetch like any other. The pickups and reminders stay, the source records the error and tries
again sooner, and the page says that no calendar with entries arrived. Adding a new address
that serves no calendar says so instead of showing a working source, and a file without a
single calendar entry is refused in the import assistant before anything can be confirmed.
A calendar that has entries is applied as before, also when it has fewer than last time.
For API clients:POST /waste/sources/{id}/refreshanswers 200 withoutcome: "error"and
reason: "waste_source_fetch_no_events"where it answeredoutcome: "committed"with
diff.removed;POST /waste/sourcesanswers 201 with the same outcome and reason. The four
import endpoints (/waste/import/preview,/waste/import/commitand
/waste/sources/{id}/reimport/preview,.../reimport/commit) refuse a file without calendar
entries with 400 andreason: "waste_import_no_events"where they answered 200 or 201, and a
URL source's re-import answers 502 withreason: "waste_source_fetch_no_events". Re-importing
an empty calendar no longer empties a source; delete the source instead. - Calendar: an event moved away while it was uploading stays where you put it (#1926). The
legacy Apple Calendar connection uploads the events of the default calendar to iCloud. If an
event was moved to another local calendar in the moment its upload was running, it was recorded
as uploaded anyway: it was on iCloud and had lost the calendar it had just been given. The same
could happen with Google when an event gave up its Google calendar during the upload, and an
event deleted in that moment stayed behind at Google. Now such an event stays local and keeps
its calendar, and the copy that reached the provider is removed on the next sync. - Google Calendar: an edit made while the event is uploading is sent afterwards (#1932).
Sending a new event to Google takes a moment. If you changed its title, time or another
detail in that moment, Google kept the event as it was before the edit and Yuvomi recorded it
as up to date, so the change never reached Google - and the next sync could write Google's
older version back over your edit. Yuvomi now looks at the event again after Google has
answered and sends an edit made in the meantime with the next sync. CalDAV and iCloud already
did this (#1862). - Shopping: an error message is in your language (#1909). When something could not be
saved, the note showed the server's own sentence, in English or German whatever the app was set
to - "Unbekannte Liste." in an English session, when an item was moved to a list somebody had
just deleted. The shopping page now says it in the language of the app: the list, item, shop or
category no longer exists, or a shop of that name already exists (choose a different name). The
same goes for the dialogs that manage shops and shopping categories. Anything else on the shopping page shows the general sentence instead of a server
text. The other pages are unchanged for now and follow module by module. For API clients: the
affected answers of/api/v1/shoppingcarry a
reasonnext toerror(shopping_list_not_found,shopping_item_not_found,
shopping_store_not_found,shopping_store_exists,shopping_category_not_found,
category_exists,category_last); status codes are unchanged, and three Germanerror
sentences are now English ("Unknown list.", "Unknown store.", "Store already exists."). - Shopping: the page catches up by itself when something is gone (#1909). If somebody else
in the household deleted a list, an item, a shop or a category while your page was open, the
next thing you did with it failed, and the note told you to reload the page. The page now does
that for you: it fetches the lists, shops, categories and items again and shows the current
state, and the note only says what happened ("This item no longer exists."). If the list you
were looking at is gone, you land on the first remaining one. An edit dialog for an item that
no longer exists closes; in any other case it stays open with what you typed and offers the
current lists, shops and categories. The dialogs that manage shops and shopping categories
refresh their rows the same way. One case stays quiet: if you delete an item that somebody else
has already deleted, it is simply gone - no note, and the row does not come back for a moment.
The same holds for a list, a shop or a shopping category that somebody else deleted first: the
list stays gone without a note, and the dialog confirms the shop or category as deleted instead
of reporting an error. - Waste collection: an error message is in your language and names the cause (#1909). The
waste page showed the server's own English sentence when something could not be saved, for
example "anchor_date must fall on month_day itself (its day-of-month must equal month_day)."
for a monthly schedule whose first pickup is not on the chosen day. Types, schedules, moved or
skipped pickups, one-off pickups, the rename and mapping of a source and the reminder settings
now say it in the language of the app, each cause with its own sentence: no weekday chosen, the
end date before the first pickup, an interval or day of the month out of range, a first pickup
that does not fall on the chosen day, a missing date, a pickup moved to the day it is already
on, a reminder outside 0 to 14 days or without a time. If somebody else in the household
deleted the type, schedule, pickup or source in the meantime, the note says so, an open dialog
closes and the page fetches the current state by itself. Deleting something that is already
deleted, or resetting a pickup that is already back on its day, simply succeeds. Saving a
reminder with an emptied time field no longer ends in a server error. The ICS import, the
mapping profile and sources with an address say it the same way, with the number where the
cause has one: a calendar larger than the upload limit, with more entries, pickups or labels
than the import takes, an address that is none or does not start with https://, an interval
out of range, a source that is being refreshed right now. A calendar that could not be fetched
says why by its kind - the address answered but delivered no calendar, the calendar is too
large, the address is on a private network, or it cannot be reached - instead of
"Fetching the source URL failed: HTTP 404". A file over the limit is refused before it is
sent. If only the type you picked in a dialog is gone (a schedule, a one-off pickup, a mapping
of a source, an import decision), the dialog stays open with everything you entered, the list
of types is fetched again and the focus is on it; nothing else is chosen in its place. The
failure text a source keeps from its last automatic fetch, shown in the source dialog, is
still the server's. For API clients: the affected answers of/api/v1/wastecarry areason
next toerror(waste_*_not_found,waste_type_in_use,waste_pickup_exists,
waste_schedule_*,waste_pickup_date_invalid,waste_override_*,waste_reminder_*,
waste_import_*,waste_profile_*,waste_source_*, listed in the OpenAPI description), and
paramswith the number where the cause has one ({ "limit_mb": 5 }); a refresh or create
that ends withoutcome: "error"names the class of the failed fetch asreasonindata.
Status codes anderrortexts are unchanged, except that an emptydelivery_timeon
PUT /waste/reminder-settings/{typeId}now answers 400 instead of 500. - Two texts no longer suggest that wall mode follows the arrangement of the overview (#1908).
Wall mode always shows the same four things - the time, today's schedule, who's up today and
the weather - on every device. The hint under Settings → Household → Wall tablets now names
them, and the note shown when entering wall mode calls it a fixed programme, independent of
your overview. The household default still sets a wall tablet's normal overview, as before;
nothing about the behaviour changes. - A task due late tomorrow evening is no longer labelled "Due today" on the dashboard. A task
due tomorrow at 22:00 or later and less than 24 hours away gets its own label next to the date,
"Due soon". In English and 17 other languages that label carried the text of "Due today", so the
tile said "today" in front of tomorrow's date. It now reads "Due soon" in each of them. Dutch
gets its own label with the Dutch wording corrections below (#1892). - An archived shared-expense group now refuses changes on the server too (#1747). Until now only
the page was locked: an API client or a stale tab could still add, edit or delete expenses,
comments, settlements and recurring expenses in a group the household had put away, and the
hourly run kept booking its recurring expenses. Every write on an archived group is now answered
with 409 (group_archived) and changes nothing; restoring the group, reading it and deleting it
under the existing rules work as before. The hourly run skips an archived group without booking
or pausing anything, and restoring the group moves its active recurring expenses to their first
date from today on, so the months in between are never booked afterwards. - Moving an event to another CalDAV calendar no longer leaves it in both (#1861). A move
stores the event in the new calendar and then removes it from the old one. When the server
stored the copy but refused the removal - an old calendar that is shared read-only, or a server
that was briefly overloaded - Yuvomi booked the move as done and never tried again: every other
app on that account showed the event twice from then on, and in Yuvomi it could jump back to
its old calendar. The refused removal is now remembered and tried again with every sync, up to
five times like any other refused deletion, and until then Yuvomi shows the event once, in the
calendar you moved it to. After the fifth refusal Yuvomi gives up, and the event stays in both
calendars until you remove one copy yourself. Events that were left doubled before the update
are not cleaned up. A removal that is still waiting only takes the entry as it was when you
moved the event (#1883): if the entry in the old calendar has been changed since, or the event
was put back there from another app, Yuvomi no longer removes it. - Editing or deleting an entry while it is being uploaded is no longer lost or undone
(#1862). Sending an entry to a CalDAV or iCloud server takes a moment, and Yuvomi booked the
result against the entry as it was before that moment. If you deleted a new event, task or
shopping item while it was being uploaded, it stayed on the server and came back with the next
sync. If you edited it during the upload, or edited an event while others were being uploaded
before it, the server kept the old text and the next sync wrote that old text back over your
edit. And a second edit to a task or shopping item made while the first one was on its way was
replaced by the first. Yuvomi now looks at the entry again after the server has answered: an
entry deleted in the meantime is removed from the server too, and an edit made in the meantime
is sent after it. - Changing where an entry is synced to while it is being uploaded is now followed (#1881). If
you picked another CalDAV calendar for a new event, or set it back to "Local", in the moment
its upload was on the way, the event stayed in the calendar it had just been sent to, and saving
it again changed nothing. It now ends up where you last put it: moved to the other calendar of
the same account, or removed from the server again and kept as a local event (or uploaded
through the other account, if you chose one). The same holds for a new task whose reminder list
you changed or took back during the upload, and for a new shopping item that left its synced
list in that moment. Until now such a task also lost the list you had just chosen and stayed in
the old one. - An entry deleted after an interrupted upload no longer comes back (#1882). When a new
event, task or shopping item reached the CalDAV or iCloud server but the server's answer got
lost on the way - a dropped connection, a timeout, a server error after saving - Yuvomi kept
the entry as not yet uploaded. If you deleted it before the next sync, the copy stayed on the
server and the next sync brought the deleted entry back. If you instead picked another calendar
or list for it, or set it back to "Local", the next sync added the server copy as a second
entry. Yuvomi now remembers that an upload was sent and never confirmed: the next sync removes
the copy from the server instead of importing it, and the entry ends up only where you last
put it. The copy is removed with the next sync run, not at the moment you delete the entry,
and only after Yuvomi has read that the entry at that address is really its own. An upload
that the server finishes late is covered for 24 hours after the last attempt. A copy that is
still waiting to be removed does not keep an event or task in Yuvomi (#1905): if the entry has
meanwhile gone to another calendar or list of the same account and is deleted there in another
app, it disappears from Yuvomi with the next sync, also while the server refuses to remove the
old copy. A shopping item in that situation stays and returns to the list of the copy that is
left, as before. - A CalDAV event belongs to the account that brought it (#1860). With two or more CalDAV
accounts, an event was identified by its UID alone. When a second account served an event with
the same UID, it took over the entry of the first: title, calendar and address then came from
the second account, and an edit made in Yuvomi went there. An event now belongs to one account
and is changed, moved and deleted only through that account. The same UID in two accounts is
still shown once, and it belongs to the account that delivered it first; if that account is
removed or no longer has the event, the other account takes it on with its next sync. What to
know after the update:- Existing events are assigned to their account automatically. With several accounts, an event
whose calendar is in the selection of more than one account, or of none, cannot be assigned
with certainty. It stays without an account, is not sent to any server, and is taken on by
the first account that delivers it at the next sync. A change you made to such an event
before the update and that had not been sent yet is not sent and is dropped after five sync
runs; the event then shows what the server has. - With exactly one CalDAV account, all existing CalDAV events go to it, including leftovers of
an account that was removed earlier. - A deletion that was still waiting to be sent and cannot be assigned to an account is dropped.
The event may come back once with the next sync; delete it again then. - Two different events that happen to carry the same UID in two accounts show as one.
- As a sync target, Yuvomi accepts only a calendar that is switched on for that account - the
ones the event form offers. A new target outside that selection is rejected. A target saved
earlier for a calendar that has since been switched off stays as it is, but the event is no
longer uploaded until the calendar is switched on again; changing it to one of the offered
calendars works. An event that is already synchronised can only be moved to another calendar
of its own account. - Pointing an account at a different server or a different user drops its deletions that were
still waiting to be sent, since they named objects on the old server. - Deleting an account while keeping its events drops any edits of those events that had not
been sent yet. - An event that belongs to no account is deleted only in Yuvomi, never at a server.
- Events without an account that no account delivers any more stay until you delete them.
- If you delete an event that a second account also keeps as its own copy, that account adds it
back on its next sync.
- Existing events are assigned to their account automatically. With several accounts, an event
- Norwegian Bokmål reads more naturally. A second pass over the app
and the installer after using them day to day: one word for a shift ("vakt"), a reminder
("påminnelse") and a tablet ("nettbrett") throughout, "container" and "image" for Docker
instead of literal translations, and singular forms for a count of one instead of "(er)". - Dutch wording corrections from daily use (#1892). The notes module was called "Bord" in the
navigation, as its page title and in the API token scopes, and "Notities" elsewhere; it is
"Notities" in all three now. The due labels on the dashboard, in Tasks, Housekeeping and health
prevention read "Vervalt vandaag" and "Vervalt morgen" instead of "Vandaag vervallen" and
"Morgen vervallen", and the dashboard's "Due soon" label has its own text, "Vervalt
binnenkort", where it repeated the one for today. The empty housekeeping tile says
"huishoudhulp" instead of "huishoudelijke hulp". - Deleting an entry of a switched-off CalDAV calendar or reminder list no longer deletes it on
the server, and is no longer lost or stuck (#1884). Switching a calendar or reminder list off
in Settings is meant to leave everything in it alone. A deletion made in Yuvomi for an entry of
such a calendar was sent to the server right away all the same; if the server refused it five
times, Yuvomi gave up, and the deleted event came back when you switched the calendar on
again. For tasks and shopping items the deletion always went through.
In other cases the deletion waited for good, also after the calendar itself had been deleted on
the server. Now the deletion waits while the calendar or list is switched off: nothing is
deleted there, and waiting does not use up its retries. It is carried out when you switch the
calendar or list on again, so the entry does not come back, and it is dropped when the
calendar or list no longer exists on the server or the account is removed. The sync log names
how many deletions are waiting. For iCloud, a deletion for a calendar that no longer exists is
dropped the same way. - A paired wall tablet can show the photo screensaver (#1766). Its account could not read the
screensaver photos, so the screensaver never started on the one device it was built for. An
administrator now switches it on per tablet under Settings → Household → Wall tablets; it is off
until then, so a wall that shows the calendar today keeps showing it after the update. A tablet
that has it on reads the same photos every signed-in device shows - with their date, city and
country - and nothing else of the screensaver: the Immich connection stays out of its reach.
The switch reaches a tablet nobody touches in both directions: a screensaver that could not
get its photos asks again after the next idle period instead of waiting for a touch, and one
whose next photo is refused closes instead of leaving a black screen. - Shopping: deleting a shop no longer says "Category deleted" (#1929). The shop manager
borrowed three messages from the category managers: adding, renaming and deleting a shop each
ended with "Category ...", and a screen reader announced the delete button as "Delete category
". All four now name the shop, in every language; the category managers read as before.
A deleted shopping list also no longer leaves its "Checked off is open" entry behind in the
browser's storage. - Health: a switched-off medication no longer shows a dose as due today (#1950). The Health page
listed a dose under "Due today" and among the next reminders for a medication that was no longer
active, while the Overview tile and the reminders left it out. The page now leaves it out too,
so both show the same number, and adherence and the streak count only the medications still
being taken. The medication stays in the list, and the doses already logged stay in the intake
log. - Wall mode on a phone: the note on entering no longer covers the clock, and the footer shows
that the list goes on (#1917). Up to a width of about 834 px the note that explains wall mode
lay on the time and date for eight seconds; it now sits directly below them and still clear of
the timer buttons, and on wider screens it stays where it was, next to the clock. Any later
message on the wall keeps the clock and the footer free in the same way. "Who's up today" was
never cut off, but the footer that stays at the bottom covered faces behind a hard edge; on a
phone the content now fades out softly above the footer, and at the end of the list the last
entry stands clear of it. On a tablet or a wall display the layout is unchanged.