#Frontend

1 messages ยท Page 1 of 1 (latest)

night goblet
#

Chill chat about the development of the frontend for Home Assistant, including accessibility topics and dashboards.

Please try to limit legitimate support issues to #1257019582112334014. ๐Ÿ™

delicate sequoia
#

The entities page was recently changed to cut out the device name from entity name. This means that to properly interpret the entity name the device name is needed for context. The problem is that it is not possible to move the device name column before entity name column, preventing the right presentation of that information.

afbeelding.png
lean crater
#

In the same topic โ€“ a new approach to area/device/entity naming โ€“ I've created a topic initially in #1284966540617449515 but seems this could be a better place.

#

IMO this is pretty fundamental, so let me mention @night night

versed canyon
stiff ivy
#

I have been trying to change that selected tab colour for ages. The hardcoded Primary Color in the frontend makes it so you cant get the whole interface consistent.

I ended up adding app-header-selected as a backup variable so you don't have to use primary colour...

image0.jpg
fading marlin
#

I have been playing with filters lately to clean up some if the sensor data for more reliable automations. This got me thinking that it would be really nice to be able to apply a filter (or two) to an entity on the frontend, similar to rounding and unit conversions. The original value could be moved to an attribute.
Any thoughts?

versed canyon
#

I don't know if it's just me, but sometime in the last month or two the incremental frontend recompile in devcontainer is not really working anymore. It used to be pretty robust but now I'm having to restart a fresh Develop Frontend task very often as things seem to be constantly missing from the webpack.

app.js:4486 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'call')
    at __webpack_require__ (app.js:4486:31)
    at eval (state-info.ts:9:64)
    at __webpack_require__.a (app.js:4556:2)
    at eval (state-info.ts:1:21)
    at ./src/components/entity/state-info.ts (src_dialogs_more-info_ha-more-info-dialog_ts.js:1408:1)
    at __webpack_require__ (app.js:4486:31)
    at eval (state-card-alert.ts:8:82)
    at __webpack_require__.a (app.js:4556:2)
    at eval (state-card-alert.ts:1:21)

Curious if anyone else noticed similar. Usually seems to work again after stopping the Develop Frontend task and restarting it.

spice saddle
#

I've seen it too, we'll have to do a git bisect I guess to find the cause.

spice saddle
#

If you're up to it, revert to v1.4.10 in your package.json for both rspack dependencies and see if it's better.

slim matrix
#

#devs_frontend-archived message i am picking this up again, it'll be the project i finish the summer with

things are going good so far - even though i started from scratch i've managed to get the auth page working and rewrite a few things to take advantage of vite, eg directly importing css and json

#

i need to figure out why all of these chunks are being generated, probably an import() gone wrong

image.png
slim matrix
slim matrix
quasi ore
#

To who can I reach out to interfere/help with the CSS variables and consistent use of it throughout the code?

spice saddle
#

You can just ask it here, whoever wants can answer if they know the answer.

quasi ore
#

Allright... I'm having problems with several CSS Variables to change them and customise them in my theme.
For example in bronx.yaml (theme):
bronx-font-family: "Hind"
ha-font-family-code: "var(--bronx-font-family)"
code-editor-font-size: "0.9em"

Doesn;t seem to change anything. That seems to happen with a lot of them. Some work, some does not seem to work.

#

All the --feature-* CSS variables doesn't seem to work either. And I can sum up al lot more...

#

Am I doing something wrong?

#

Or are things just not working sometimes? And is that a bug, which should be reported?

versed canyon
#

I think theming is very much a "you're on your own" kind of activity.
We have a (very very short) list of "supported theme variables" , which I think we expect to work consistently. Everything else is pretty much YMMV.
I guess if something beyond that is not working you could try opening an issue, I don't know if anyone will acknowledge it though.
You could also try the community forums, I know a lot of people do some pretty advanced theming and discuss it there.

spice saddle
#

If you don't include the font-family that you're setting there, nothing will happen.

#

Some font families are preloaded by your browser, but that one definiately is not

quasi ore
#

And added to the sources-tab as javascript module

quasi ore
spice saddle
#

Then it sounds like a bug.

broken cave
quasi ore
stiff ivy
#

The new 24px spacing pushed to the tab group looks crap on phone!

#

I removed the padding-inline overrides and changed .tab to have padding of 1.25 em, so it looks as good as before this commit...

inland elk
#

Did we ever explore how we can start restoring scroll position when a user naviates back

inland elk
#

I think that we should have two default method on our views that get called by the router, which defaults does nothing.

getScrollState(): unknown;
setScrollState(data: unknown);
#

and then one by one, we can start updating views

inland elk
#

The toast for new frontend is not dismissable. Also, it wasn't on top so dialog button got taps while not visible. Should we make this dismissable?

image0.png
spice saddle
#

It's always a good thing to do reload there, so I wouldn't add a dismiss.

quasi ore
#

I always asked myself why that toast-message thing is at the bottom, and not more prominent in the middle of the screen. Like a popup, on top of everything...

quasi ore
inland elk
#

Well what if you're editing an automation

#

You lose progress

quasi ore
#

Shouldn't that be just part of the workflow, and be executed at submission?

inland elk
#

Ah so the edit automation would tell the frontend that we're editing something, so wait with restart. Once user hits back or save, the automation editor releases the lock, pending restart is applied. I like that idea a lot. We should also do that for dashboards. We also show a "newer dashboard available" toast.

quasi ore
# inland elk Ah so the edit automation would tell the frontend that we're editing something, ...

Yes, that's what I mean. Inform the user and give it an option for restarting the system to do it immediatly (with a countdown timer of say 30 sec), or to do it manually later...
The same with reloading cache after front end changes, which should be cleared right away after execution. This doesn't need a pop-up to prsent the options. There is no reason, to not update your cache after a front end change to clear cache.

inland elk
#

Anyone tried this yet? https://x.com/addyosmani/status/1984713138454085925

Addy Osmani (@addyosmani)

New in @ChromeDevTools! Debug an app's full performance trace with Gemini!

After recording a trace, you can now chat with Gemini about the entire trace, related Performance insights, and even connected field data - all without needing to select specific context beforehand!

X ยท
inland elk
# 
 uv pip install home-assistant-frontend==20251105.0
Resolved 1 package in 1ms
โ ฆ Preparing packages... (0/1)
home-assistant-frontend ------------------------------ 6.03 MiB/90.23 MiB
#

How did our frontend get to almost 100 MB??

spice saddle
#

Dashboard features and automation features. Mainly new components.

inland elk
#

I doubt that, it used to be 50, which includes the build four times. With and without es5 and with and without gzip

inland elk
inland elk
#

We can drop 31 MB if we drop gzip. We already have brotli, so gzip is only to support browsers from <2017. Especially frontend_latest does not need gzip files, because all browsers that fetch that JS support brotli

#

one could argue, brotli for frontend_latest, gzip for frontend_es5

# 
โฏ find . -type f -name "*.gz" -exec du -ch {} + | tail -1
 31M    total
โฏ find . -type f -name "*.br" -exec du -ch {} + | tail -1
 29M    total
spice saddle
#

Nice finding, the reasoning behind the increase of new components is mainly from relative ci, which is run on every pull request and also shows an increase over the last year.

#

It was already discussed in the past to rely on brotli, but was kept back for a reason.

inland elk
#

Ah, good find. Yeah so we can still drop brotli for es5 build i guess

inland elk
#

Interesting side effect: I didnโ€™t update my dev env to Node 22 yet. When I did, it couldnโ€™t find yarn. Nowadays, you need to install yarn by using npm install -g corepack. However, npm install fails because we have yarn specific patches

โฏ npm install corepack
npm error code EUNSUPPORTEDPROTOCOL
npm error Unsupported URL Type "patch:": patch:@material/mwc-formfield@npm%3A0.27.0#~/.yarn/patches/@material-mwc-formfield-npm-0.27.0-9528cb60f6.patch
npm error A complete log of this run can be found in: /Users/paulus/.npm/_logs/2025-11-13T04_02_58_458Z-debug-0.log

I fixed it by going out of the frontend repo and installing it globally, after which corepack installed yarn correctly

#

I ran STATS=1 script/build_frontend to dive into the bundle. And we are shipping quite some weird packages in our main bundle app.js. For example, 31kB goes towards superstruct, but that's a data validation library. How did that end up in our main bundle? We also include 4kB of just color names ๐Ÿ˜ฌ

CleanShot_2025-11-12_at_23.10.522x.png
#

How do we determine what core.js things are bundled? We always tried to keep the core.js entrypoint TINY so it can load quick, establish connection/auth, so by the time app.js was loaded, all data from the server had arrived over the WS server. Now this 71kB file contains 66kB core-js ! The rest is still tiny as designed (1.2kB core.ts entrypoint, 3.82kB HAWS).

CleanShot_2025-11-12_at_23.15.392x.png
#

Who is the person working on rspack? Because this feels like a regression that slipped in that we should address

#

The reason app.js and core.js are not sharing code is because core.js always got bundled by itself, to avoid relying on any other file. This is important to keep it tiny and fast.

spice saddle
#

Wendelin introduced it in the frontend.

#

Interesting observations btw.

frozen epoch
#

Yep I worked on it last year to improve our build time, yeah weird. I would need to take time to look into that

spice saddle
#

Based on bisecting the release builds, it should be around that time.

#

The size went from 59 mb to 80 mb around new year when we brought back zopli, then increased every release until today to 92 mb

inland elk
#

It's interesting to see the quick growth from 80mb to 92mb

#

I guess translations don't help either

image.png
#

that's the space it takes just for Arabic translations of the config panel ๐Ÿ™ˆ

inland elk
#

Was messing with the climate panel, trying to see if we can have a graph shown. Is it possible to have 2 cards in a row. The first one is width 3, while the other one takes up all the rest of the space? I tried to set "columns: full" but it would bump it to the next row

lime otter
#

Small thing I run in to from time to time. When creating an automation but then you want to back out of it, these buttons create a "loop" - they bring you back to the other page.

Makes sense, but my intuative feeling was that I was going to be taken back to the automations overview page when closing the save dialogue. (Now you need to move your thumb across the whole screen to press "Don't save").

Maybe a confirmation dialogue when closing the save pane would be better?

IMG_0795.JPEG IMG_0796.JPEG
inland elk
#

Can the whole folder src/panels/map be deleted? We don't register it anymore in the backend

inland elk
#

I had forgotten how easy it is to set up dev env to work on supervisor frontend stuff.

inland elk
inland elk
inland elk
#

@frozen epoch I just saw that you closed the PR of Karwost on updating the theme service with the reason

Designs for system theme settings will be made and it's going to be a project, which also includes the rework of the theme service calls.

This pull request is an improvement of the current logic of how set theme action works. It's a big improvement in UX. Holding back on improvements today for if we find time in the future to do a whole revamp is how progress stalls. We always want to do full revamps of all the things all the time โ€“ prioritizing things might push this project out 1+ year, and this improvement from Karwost would solve a lot of frustration in the meanwhile!

frozen epoch
# inland elk <@333876705745960963> I just saw that you closed the PR of Karwost on updating t...

Hey, it was a group decision. The main part of yesterdays meeting was about this, and we had a lot to discuss so we don't want to do a service call api change here if we going to change it again in 1 or 2 months.

  • Should we keep setting 2 themes or force the theme creators more to always provide a dark theme
  • Default theme is actual the system theme. Should we rename it?
  • The 1. theme should be mandatory in the service call and the 2nd option should be an optional overwrite of the 1. dark mode
  • Should we also create a service call to set the system theme mode?
  • Should we even keep this theme set service call?
  • What about user themes, not just overwrite per browser

@restive granite will create designs and on this basis we continue to make all of this decisions.

inland elk
#

Yeah I don't want to doubt the discussion, I only have doubts about the 1-2 months ๐Ÿ˜…

restive granite
inland elk
#

I just noticed the snowflakes code in the main entrypoint ??? We literally load the sidebar later in that same very file, to save on bytes and processing and we put the snowflakes right in the hot path when the app opens ๐Ÿ’€

inland elk
inland elk
night night
left crater
broken cave
left crater
#

Ok

severe egret
#

@jolly panther this chat is about the frontend development ๐Ÿ™‚ The right place would be #1284960456880029707 ๐Ÿ™‚

jolly panther
severe egret
#

No worries ๐Ÿ™‚

inland elk
#

We should ban this log icon from being used. It makes no sense as it's not an icon.

image0.png
sudden tartan
#

Changed to something like this :

CleanShot_2026-01-20_at_10.22.17.png
trail scaffold
#

I was wondering what's HA/OHF team stance on adding a user-choice screen? I wanted to ask before making a FR.

For example, you can give the admin an option to choose what Zigbee platform to use as the default (ZHA/Z2M). So, the the frontend elements adapt to their preference. Example of this would be the new Protocol section under Settings; it would also make it feel more integrated.

That's just one example, but there could be other possibilities down the line.

inland elk
#

Z2M is based on MQTT, there is no notion of a Z2M integration in HA

#

so HA cannot tell users about Zigbee2MQTT because HA does not know it exists

trail scaffold
#

Ah that's unfortunate, thanks anyways

#

Maybe MQTT can be displayed instead, and show connection by pulling device info here?

Screenshot_2026-01-21_at_12.35.35.png
inland elk
#

Today from a call: why are the lights in the mudroom disabled. The off-icon was misinterpreted

CleanShot_2026-01-21_at_15.29.052x.png
broken cave
inland elk
#

The on lights are colored, so maybe a line is not needed

broken cave
#

That would make it harder for e-ink or visual impaired people No?

#

Oh wait color blind doesn't have to apply here

kind ivy
#

The problem with icons that change state is once you change the icon to something else, the state of the icon will no longer change

#

And that's a flaw that I'm not even sure can be resolved without abandoning icons for important information and delegating it to visual indicators and text information

versed canyon
inland elk
#

So today I was playing with https://github.com/homeassistant-ai/ha-mcp and it's pretty amazing. I asked it to make a dashboard for my vacuums and it produced this. That's excellent.

Now, I would love to make this kind of features available inside HA, but it comes at a big change for Home Assistant: core will need to become aware of how the dashboard is structured. Right now, the fronted just saves YAML and the backend just accepts it.

Once we allow tools to maintain dashboards, we're going to get code like this https://github.com/homeassistant-ai/ha-mcp/blob/master/src/ha_mcp/tools/tools_config_dashboards.py#L222

image.png
#

I think it's fine, it's time and the new feature can make it really easy for people to get started with new dashboards.

#

Anyone see any concerns ?

sour vessel
#

Can it do this as a JS strategy so it still lives in the frontend?

#

I'm that concerned that core will be creating dashboards but we already have a mechanism for this specifically

inland elk
#

LLM tools are executed in the backend, so cannot live in the frontend

sour vessel
#

No I mean use the LLM to create a JS custom strategy and add it as a frontend resource

inland elk
#

Ah, but then users cannot edit it

sour vessel
#

I was thinking the user can take over and get a yaml but we haven't actually made that available. I think we should have that for every strategy. They all generate yaml compatible configs anyway

#

Something for the future I guess. For now it's good to just get a starting point ๐Ÿ‘

inland elk
#

Looks like demo is not having correct data for the entities and more info header is showing entity ID

image.png
spice saddle
#

It's already fixed on dev. ๐Ÿ˜„

sudden tartan
sour vessel
#

Yes but then it is static and you have to prompt it again for every new device

sudden tartan
#

We must create some section strategies (using target picker as entry) and document it. So IA can use it to create the dashboard

inland elk
quasi ore
#

Not sure if this belongs here, but aren't the /logbook and /history links in the navigation menu (left) referring to the same functionality? And could one of the links be superseeded by the other?

sour vessel
#

They are slightly different but it does make sense to have them as tabs of the same panel imo

quasi ore
#

What is the actual difference beisdes the fact that /history doesn;t display anything at the first click, and /logbook does have an actual overview of state changes/events for the past xxx time?

#

Nothing in the documentation about that, and to me it feels as a 1:1

sour vessel
#

history shows graphs of the state history, while logbook/activity shows a list of events. They are very related but different data

quasi ore
#

@sour vessel the /logbook and /history are the url's on your HA instance.
/history doesn't display different graphs than /logbook, once clicked in my installation.
IMO these 2 url's are very equally the same, and only the presentation differs, not very much in function. But perhaps it does differ in uasge?

sour vessel
#

/logbook and /history are different pages. Only their date picker is the same. If you don't see a difference, there is something wrong with your instance. Maybe a custom panel is overwriting one of the urls

quasi ore
#

I'll look into it... Though it feels these could be combined into 1 page, because they seem to be clsely related to each other imo

inland elk
quasi ore
#

The same would apply to themes.
I want to set the theme site wide, and do not want to give the option on a per-user base to change or set it...
And I don't think I'm the only one

sour vessel
#

That seems hostile to users tbh. You can somewhat limit themes by just not having themes, I guess

quasi ore
#

Why? I am the admin afterall. I know what is best for all my users ๐Ÿ˜‰

#

And sometimes, having the opportunity to restrict some configuration per-user is for the better.

sudden tartan
#

You can already set a theme at system level (but you must use action for that). We thought about exposing this as a settings directly

quasi ore
#

I know... But how could I restrict users to set another theme? Or date format? Or language?

sudden tartan
#

Then I don't agree, admin must be able to set default but user must be in control if he/she want.

quasi ore
#

Why @sudden tartan?

#

Home Assistant is an assistant in your home or small office. It is possible that someone speaks another language inside your own household, but the chance that they do, is not very common. (I dare to state that the use case of this is way less than 50%.)
Which also reflects why I would love to see an option for a general custom date/theme/language-option without giving users the choice to change them.

IMO his could be a general setting, which sets the global setting with an option to present the option on a per-user base or use the general (date/theme/language)-option.

I'm not saying to remove/delete the per-user options. I'm just saying there should perhaps be an option to let the admin decide if these things should be configurable on a per-user base or not.
And if not, don't present the option in the personal user configuration/settings page

sudden tartan
#

I agree to have system settings. And user settings to override these settings (even in an advanced section as it's not really common). But I do want to put effort in adding option to block things because it opens the door to many rules and it leads to many edge case (we have to reset the user settings if the admin choose to block, etc...). IMO, it adds lot of complexity and potential issue for no real benefit.

quasi ore
#

The benefit will be a better UI/UX experience for users, where less (options) is more.

#

And give the true power to the admin to make the decision

sudden tartan
#

Then put it in an advanced section, problem solved.
It will not remove option bu default for user as the default will be "let users choose"

inland elk
rain mesa
#

is there any place we can have a quick chat with the frontend team about https://github.com/home-assistant/frontend/pull/29186? it is merged and people are now starting to get annoyed with it, but comments in that PR are left unanswered of course. Even though Timmo suggests having more eyes in it and talk in Discord?

GitHub
Move entity attributes to three-dots menu subview by marcinbauer85 ...

Summary

Move entity attributes from inline display to a dedicated subview in the more-info dialog
Add &quot;Attributes&quot; menu item to the three-dots menu
Only show the menu item when t...

sour vessel
#

Heads up: The grid format for energy is changed in https://github.com/home-assistant/frontend/pull/29389
There is a migration in core but until the next release frontend dev will have some incompatibility with the prod version of core, so develop_and_serve will have issues in the energy dashboard

GitHub
Migrate grid connections to single objects with import/export/power...

Proposed change
Refactor grid energy configuration from legacy format to unified grid connection objects (like batteries). Each grid connection is now a single object with import/export/power toget...

thick siren
# rain mesa is there any place we can have a quick chat with the frontend team about https:/...

This is probably the place. I also initially thought we now show all attributes, but now taking a second look, I can see there is a list of specific attributes which are hidden still: https://github.com/home-assistant/frontend/blob/e72facdec8c3513e1f7646e49b54bcf8adb01b2a/src/data/entity/entity_attributes.ts#L4-L29

We definitely show more now, there were specific domains hiding extra attributes on top of this default list, light for example: https://github.com/home-assistant/frontend/pull/29186/changes#diff-56c35604c211ca080df585f0d957f7bf03d2a3388d67594b3d6117e9296da9adL305

rain mesa
#

exactly that list was reason for me in the past to figure out how to 'unhide' several of those. People have different thoughts about 'useful info' ๐Ÿ˜‰
But to centralize discussion, (Marcin also added comment in the PR now): where to continue?

sour vessel
#

I thought we agreed to show all attributes now that they have a dedicated tab. So the remaining hiding is probably just an oversight

rain mesa
#

to be fair, in that list, there are a lot of attributes that would probably suit only being shown in dev tools... a generic 'show all' would be not the ideal solution either, as that would make the now dedicated attributes card overloaded with info that was hidden justly. And worsen the situation even further... imho.

thick siren
#

Can you see any in these lists that you think should be shown in this section?

rain mesa
rain mesa
# thick siren Can you see any in these lists that you think should be shown in this section?

well, if you'd ask me, I would certainly require the display of options, and of the state_attributes, Id need device_class, entity_picture, event_types, icon, last_reset, state_class, unit_of_measurement and available_tones. ( actually do use that last one ๐Ÿ˜‰ )

I also believe attribution should remain on the more-info main card, as that is also valid for the main entity, and not only for the attributes.

entity_id is already available in the more-info dialog cogwheel, and I suppose the other hidden attributes can remain as is supported_features, initial_state, restored. If they are still around even (haaska_xx?, or the custom_ui_xxx)

thick siren
#

What is attribution for the uninitiated?

rain mesa
#

it shows the source of the info, which seems rather important, especially to the uninitiated.

thick siren
#

Oh isn't this the "Provided by x" at the bottom? This has been removed?

rain mesa
#

yes

#

and its not even showing attributes in the 3-dots

Schermafbeelding_2026-02-16_om_11.55.22.png
#

it does show in another entity of the same integration

Schermafbeelding_2026-02-16_om_11.55.05.png
#

to me this is all very inconsistent and having that back in the main more-info dialog under the fold seems so much easier. And neat.

south wharf
thick siren
#

Ah yes, its showing on the latest build:

image.png
rain mesa
#

not sure what you mean now, as the attribution is not gone in current 2026.2.2 on the weather entity?

#

it has been taken out of all the individual other entities however..

kind ivy
sweet trout
inland elk
#

Can we pre-select areas that have same name as the vacuum room name ?

image.png
night night
#

How would you know the difference between pre-selected and set values?

inland elk
#

We wouldn't care. We would just select on the right areas that match the area. User can click on "Save" to confirm, or clear areas that don't match

#

We would most likely have a 80% correct rate, corrections would be rare

#

I mean, I would probably even lean to just try to automatically map it without raising a repair. Some things will go wrong, but then the user corrects it. A lot nicer approach than having a repair issue for every vacuum entity + extra onboarding

#

I also want to update some of the text. All menu items are written like a topic (Voice Assistants, Enabled etc). "Map vacuum segments to areas" is way too techical, the description is ok. I don't like the word segment, it's a brand new word.

Maybe just "Configure vacuum areas"

image.png
#

The dialog to map segment,s when you hit "Save", the save button just gets disabled (as if it is actively saving), but that's actually done state. You have to click back. It is a very confusing UX .

broken talon
#

the Dreame integration uses the word "zones," idk if that's expected terminology or if Tasshack just came up with it

#

but honestly, "Configure areas" (or just "Areas") would still send you in the right direction.

delicate sequoia
delicate sequoia
restive granite
#

I would present it as a prefilled suggestion in both the add flow and the repair flow. The user should confirm any suggestion, especially in case it might be a fluke.

inland elk
#

How do users know they can add a dashboard? Rename an entity? We still give reasonable defaults that work for people instead of forcing blank slates.

#

We need to default that mapping and kill the repair issue.

delicate sequoia
# inland elk This is exactly how Home Assistant becomes so complicated, because we don't dare...

The solution here is for users to set the mapping. Any sort of heuristic in the background is not a solution at all, it's asking for trouble and confusion.
The only thing missing currently is for the frontend to try to auto match the area names and prefill the selection, users can then easily confirm it, or edit if needed. That also means that they know it exists, so there is no gap of understanding.

inland elk
#

What trouble? It won't break things

#

Worst case it cleans the wrong location

#

But more likely the mapping fails

delicate sequoia
#

Worst case it doesn't clean at all, and you don't know what to do about it.

inland elk
#

No, the action fails

#

Because an area is not mapped

delicate sequoia
#

Put yourself in the shoes of a new user, how do you know that mapping even exists? It's hidden deep in the entity options.

#

And also consider international audience, a lot of manufacturers put default area names in English in their vacuums, whereas areas in HA are in your native language.

#

So the percentage of users for whom this will work is way less than 80% btw.

inland elk
#

We should offer users to review their segments in the action window where a user asks a vacuum to clean areas. Thats how people find it if it doesn't work.

night night
#

Hey hey ๐Ÿ˜„

#

I don't want to be a conversation stopper

#

But....

#

We do have a #frontend channel now, which we need to move to

#

I actually want to close this project topic

inland elk
#

Heh it's so difficult ha