Opening the Ace options is done in JavaScript with editor.execCommand('showSettingsMenu'). All I really do is calling that with the onclick event.
I hope you’ll do a pull request as soon as your done with your modifications. I definitely want to include your effort.
Edit: Mentioning for completeness: The items in the file tree are a little offset. But I’m sure you’re already working on that.
Edit 2: Regarding the Ace Menu: Could be, that the material design stuff is breaking it. The default menu included with Ace is more of a demo, as applications using Ace would usually build their own menus to blend in to the rest of the design. I’ve used the toggle buttons for whitespace etc. before, but stripped them away because of the new menu. It would however be great if we had our custom menu.
And one note, as I’m seeing your dev.html is unchanged: As you work you can put your code in there. If you then set the DEV variable in configurator to True, the HTML the dev.html will be used with every refresh. That way you don’t have to paste the html into the py-file. At least for me that’s a lot less pain.
Oh wow, shoot I actually never even noticed that offset, good eye!
I’ll keep plugging at this and try to get it 100%
As far as the Ace editor menu goes, I can find where the call is, but I’m not seeing where the style is controlled. The Material Design CSS is definitely breaking it. Ah and as I’m typing this I see your new edit about creating a new menu. That would be the way to go for sure. We could add a second side nav from the right that would contain all the Ace stuff
Awesome tip about the dev.html, I wasn’t sure how that worked, I’ll play with it
Another thing I have noticed:
You took out two statements from the load-function:
editor.selection.selectFileStart();
editor.focus();
Because of that the whole text is selected after loading. I have disabled that because it’s kind of odd behaving that way. Is there any reason you have left that out? Does that somehow conflict with the material design?
Been testing your dev.html. Some feedback (here, because issues aren’t activated in your repo):
At least in the version in your repo you’ve nested your html into the existing one. So I’m seeing a mix of your work and mine.
It’s strange, that the menu on the right already opens when the mouse is hovering. Usually such menus open when clicking / tapping them.
When saving a file a modal was show that saving was succesful, or that an error occured when it fails. This is missing now, so there’s no feedback for the user. Not saying that saving worked kind of seems ok. But errors should be presented. So the return value from saving should be displayed in a modal like the about dialog.
The link to the repo in the about dialog is broken. It’s not an <a> anymore.
The header above the file-tree (with John Doe in it) should be removed as it doesn’t really serve a purpose.
Maybe personal taste, but I’d like the menu on the left (with the lists) to be a little wider. The current narrowness makes it hard to read the names of the entities.
Great feedback! I’ve enabled Issues in my repo, forgive the noobness as git is still new to me (HA reignited the flame)
Whoops, that nest was a mistake. It’s been fixed now. This has been more or less a proof of concept to me as well as getting my rookie code feet wet again.
The menu is set to hover, I agree, it should be a click. I only did this as a bandaid since onclick isn’t respecting the dropdown width for some reason.
I’ve implemented a confirmation dialog for both saving and restarting
Fixed, total oversight on my part during formatting of the modal
It is unnecessary and I have been going back and forth with it. It keeps the Material thing going, but is a huge waste of space. It’s currently removed and still looks pretty good (minus the offset which is giving me a major headache)
I agree completely. I think you’ll like the next version
I’ve checked it out. Totally awsome! The only things I see to be done are the settings menu and the file tree. About the latter: since this now becomes material, it might be an option to ditch the jstree und rebuild something custom made. Like nested <ul>'s.
The thing is, that the material library seems to mess up the CSS of jsTree, and fixing that kind of seems like the wrong approach to me. I used it as a quick was to start this. But it visually doesn’t really match now. What do you think?
It’s strange, jsTree aligns great when it’s outside of the sidenav, which is what is driving me crazy. Something in the sidenav CSS is causing the strange formatting (line-height or something), but I can’t track it down.
It would be awesome to create our own material tree, but I honestly don’t know where to begin to populate the info
For our own tree I would rework the api/files request to return something useful for our usecase. But to know what would be needed by the frontend we would at least need some prototype for a frontend tree. Maybe a demo based on icon lists with static data would help us get started.
In the short term I actually don’t see it as a too big problem with the offset tree. It’s still functional, we’re working on it, and the rest of the UI is worth the “bug”. So for me it would be acceptable to publish this with everything done except the fixed tree.
Edit: Actually, why not ditch the tree and instead do it like apps on iOs/Android? The always show a list of files and folders, and if you enter a folder a new list is displayed with an ellipses at the top to switch back to the parent folder. This would save a lot of space, and no matter how many nested directories there would be, it would always look clean. Not that HASS invites for a lot of nesting. But given that the editor allows switching syntax, people could then browse the whol filesystem and f. ex. modify their AppDaemon files.
Just a little teaser if you’re curious what’s coming:
Yes, the new filebrowser is capable of browsing the whole filesystem. Which could come in handy, but also may be a security risk. We’ll have to see what happens if the configurator is run as a dedicated hass-user. Should be doable and at least add some degree of safeness.
It looks great and the options are wonderful. I’ve just tested it running standalone and will try it embedded in HA later.
I see there is a way to save a file, but is there any way to close a file in the editing window other than opening another file or doing a Shift + F5 (refresh)?
I ask because I’d rather not leave a file open and then possibly edit it unintentionally or leave it up on the screen. Not a big deal, just a thought.
EDIT: BTW, looks flawless embedded! And I love the idea of the components as a help item - I do that all the time!
@rpitera
You are right. There currently is no way to close a file. I can add that as a to-do. I’ve already thought of also providing the option to delete and create new files. But for now that was lower priority. First step was getting the net UI in place.
@andrey
That’s my selfmade alarm-panel. It’s a relict of my alarm-system before I switched to HASS, and for now I didn’t take the time so see if HASS is capable of replacing it completely.
In short: it’s a small web-app with websockets that is running on wall-mounted tablets around the house. It has buttons to select a user, who can then enter his / her own pin to disarm the alarm and set a corresponding MQTT presence entity in HASS to home.
Thanks to HASS I can set these to home / away from tasker or whatever device I have configured. But before HASS all there was was logging in with a PIN. Which is a good fallback if the battery of some authentication toked / smartphone is dead, and I even can give a PIN to the cleaning lady without spending money on some fancy device, and if that PIN is used out of the ordinary I would know she gave it to someone else etc.
