You're absolutely right to raise this concern. The current setup limits flexibility at some point, and we recognize the need for better control over these options. We will be including the enhancements in the upcoming releases. We appreciate your feedback—it's valuable in shaping a more practical and adaptable LeptonX experience. Thanks for your cooperation!
I assume this also means that I am correct in that in order to modify this, even if it is just to change only what "icons" are displayed in the mobile navbar, you would really have to make a new version of the entire mobile navbar component?
While possible, I had a look at it and it seemed like it would be a quite daunting task which would also need to be repeated with every new update which isn't doable in the long run. This at least for the Angular UI, but I imagine it would be something similar with all UIs.
If this is something you decide to put into the future task list (which I think you should), please refund this ticket.
Thanks.
What is the reasoning that a mobile user would not need to login but a desktop (big screen) user would? Especially as it seems that empty slot in the mobile navbar is not used for something else until you actually find a way to login.
As I understand it, in this case, the only way to affect this would be to do as you say with component replacement. Considering this is a quite complex component/module, this would in reality mean that you would need to download the source code for LeptonX and make you own version of the entire mobile-navbar component to get support for dynamic menus etc. And all this just because you wanted to change the menu items displayed in the mobile navbar. And this would have to be repeated for every new ABP project.
What would actually be needed is a way to control what menu options are displayed on the mobile navbar (besides the hamburger menu), just like you can for the main menu system. I find that the LeptonX theme looses a lot of practicality because of this.
Or am I wrong?
Hi,
dynamic-env.jsonis not necessary getEnvConfig API request is related to RemoteEnvironment. You could remove the configuration if you didn't use it. https://abp.io/docs/latest/framework/ui/angular/environment#remoteenvironmentIt can work with any webserver , not just nginx.
But isn't the dynamic-env.json file there only to be overridden by the one in docker-compose folder (or rather on a mounted docker volume)? And the same probably goes for the nginx.conf file. If so, perhaps it should be highlighted more in the docs, as I think trying to setup something similar in a production environment, especially a managed one, would require different solutions (since you would probably not control the host to be able to modify the local docker-env.jsoin).
What is the status of this?
It seems like the latest version of LeptonX seem to lack the login link when in "mobile mode". It is not under the hamburger menu either.
If you (on a device that supports it) zoom out so you get the non mobile view, you can login and then if you return to the mobile view, you will se the account icon in the mobile nav menu.
It seems like the LeptonX Navbar has now been updated to replace that hideous large icon in the middle with the typical hamburger menu to the right which is a good improvement. But with only four icon spots available, please don't use one of them for Settings, which might be something that most users change perhaps once if even that. Please instead put that in the hamburger menu and instead lets us have the other spots for what is app specific.
If you login it is even worse, now 2 out of 5 icons are used for something that could be under the hamburger menu
From what I know, there is no way you can modify this either than downloading source code for LeptonX and customize it yourself?
Thanks.
On a side note, where can we track changes / roadmap for LeptonX?
Is the dynamic-env.json file even used for NON Docker setups?
From what I can see in environemnt.prod.ts, ABP relies on NGINX being setup und running and responding to /getEnvConfig but how would that happen unless you are using Docker (or configure nxinx manually). This however from what I can see is never mentioned in the docs nor the files nginx.conf or dynamic-env.json. There also now does not seem to be an option to not create support for Docker Compose so I imagine those files will always be there, along with this
remoteEnv: { url: '/getEnvConfig', mergeStrategy: 'deepmerge', },
Assuming the above is true, I think it should at least be clearly mentioned that the remoteEnv requires Docker/Nginx. Or I am wrong which would probably be better for everyone :)
The docker-compose.yml build paths seem to be wrong making the image build not working (unless you have built the images before). Problem seem to be that if you execute the run-docker script in the docker-compose folder (which I assume most would), it wont find the dockerfile.local files, or rather, the dockerfile.local files wont find what they need.
For it to work, you would need to change the build for relevant images from (for API) to something like this. This of course assumes that the release/publish folder already exist
build:
context: ../../
dockerfile: src/ImproWise.COIN.HttpApi.Host/Dockerfile.local
To
build:
context: ../../src/ImproWise.COIN.HttpApi.Host
dockerfile: Dockerfile.local
This problem is kind of masked if you run the build-images-locally script first as that would mean the images were already available, but I believe that this should still be changed so that the docker-compose can run on its own (at least assuming the publish folder is there but that is perhaps a more reasonable expectation).
Thanks.
It seems like the template creates the wrong path to DBMigrator Dockerfile.local in the YAML
coin-api: image: improwise/coin-api:latest container_name: coin-api hostname: coin-api build: context: ../../ dockerfile: src/ImproWise.COIN.HttpApi.Host/Dockerfile.local
db-migrator: image: improwise/coin-db-migrator:latest container_name: db-migrator build: context: ../../ dockerfile: src/COIN.DbMigrator/Dockerfile.local
