Wappler is not bulletproof enough to not allow for access to the file. I experience issues on a not completely uncommon basis that is easily fixed by jumping into the actual file itself and editing. Just like you need to do in the page code sometimes.
I 100% understand that they don’t want us to do it, and why - but it’s in the same sphere as requests for advanced functionality to be available for users that understand it.
So your suggestion of allowing for the same design/split/code view would suit this. This is a huge efficiency issue for me having to open the files up in Sublime.
I understand their point. They really want to provide a bulletproof solution. The problem(on our side) is that when we should be reporting a bug we just open the file in code so it’s a missed opportunity to help make it bulletproof.
But given that we can and will open the file in other text editors I see no point in not adding this as a standard functionality as it was before.
For me having VSC open is just standard operating procedure. The search functionality is a bit faster than Wappler’s one so it saves me some time. I also use it when working with js files and now with App Connect Components.
@george in any case for your reconsideration as I’ve seen quite a few people notice they are not able to open SCs in code editor.
My suggestion still stands. Add subviews to SC tabs: Flow and Code.
If the team was serious about a bullet proof solution, they would have a proper bug reporting system that is properly managed. George has made it clear they do not want that. I am now in the camp that doesn’t bother reporting bugs unless I am really bored so this potential change won’t help. I used to stop what I was doing, confirm the bug in a sandbox, and then report. I’m tired of those reports being ignored ( no comment, no assignment, no fix, no nothing). For my own sanity, I’ve just embraced the many great things about the product and accept and deal with the shortcomings on my own.
So if they ultimately do remove the edit function, they will be taking away the thing that saves us when the editor fails — It will just annoy those of us that rely upon it due to the bugs.
I applaud the team for requesting comments on all these changes, as we spend more time in this editor than they do.
+1 as well as a vote to remove the left major icon nav.
@mgaussie / @mebeingken
Having an additional option to open JSON was one of my first requests, which George hinted they might no longer support.
I am glad more users are asking for it.
I really hope @George reconsiders this.
I really think they want a 100% bulletproof solution but then we have:
Let’s focus on bugs.
But new features!
But documentation!
But mobile!
Let’s make the team bigger to fix more things.
But focused team!
But community!
Let’s change the UI so we can make things easier overall.
But I refuse to adapt
But it was easier before
We are a difficult audience
I think they want a bulletproof solution but the community will not sacrifice what’s needed for that to happen. And they are too much community focused.
I could be wrong but that is the impression I have after spending so much time in the forum.
Ken - I’m actually quite shocked to read this. Before we started the beta, we did nothing else for a few months than fixing bugs and stabilizing the product, specially your bug reports.
Seems all is quickly forgotten?
Of course there will be some bugs to always pursue but we have a very stable product already due to the hard work lately.
I always appreciate your detailed reports, which allowed us quickly to narrow down the issues.
Unfortunately not everybody is that thorough and recently we loose a lot of time to beg people for better reports and reproduction steps leading to longer to investigate.
This is so true. 80% of bug reports are not good enough to even start dedicating time to them. And it’s normally thanks to the community interacting with them that they are improved to a point where the team can confirm or deny it is one.
If they had just a private tool for bug reporting they would even waste more time in those so I do understand them wanting to keep the forum for this.
Exactly my point! Private bug reporting will cost even more time and delays because of that. The community helps a lot in investigation and discovery of the issue! Also prioritizing will be much more difficult because there is no “pressure” from the community.
And at the end it takes just as much time and effort to post a good bug report.
I’ve just had looked at the latest beta (7) - and I think the new tabs are great. The main issue issue is not being able to see the App Connect side of the screen at the same time, but hopefully this will be resolved when split screens are implemented.
The preview/edit tabs are not perhaps very intuitive, but a feature doesn’t have to be intuitive to be easy to use (often the opposite). New users will certainly need help getting to grips with what seems to me to be a rather unusual, but very clever, way to open/edit files etc.
Something I just realised (which I appreciate may be rather obvious) is that the new arrangement allows for even more screen space to be available. Having opened the Server Connect files you’re working on, the leftmost panel (Workflows) can be closed, eg with a shortcut - something not currently possible if you’re working in Server Connect. This will further increase the feasibility of implementing what could be one of my favourite new features:
But still allow code view as it is truly needed until you have covered all cases. Remember that having access to code is actually a differentiating point from other no-code solutions.
Just yesterday a solution to a problem was given by asking to change code.
If you want to avoid that unexperienced users get access to code and then that ending in unnecessary frustration and inexistent bug reports just add a new app setting.
Show code view: No, webpages only, everything.
And then set it as default to No or webpages only.
Btw we do plan to add more and more editors in tabs.
Indeed the projects settings, but also database table editors, maybe database diagrams and more.
So actually every left side panel might have a set of opened tab editors.
To help keep those tabs organized, we will be introductions also color coding for better recognition.
Maybe it is a good idea to auto show and hide tabs depending of the specific panel being visible. So like show the server connect tabs, when the server connect panel is visible and hide them otherwise.
Maybe to allow some to stay visible we can introduce something like tab pinning. So you can pin a tab to let it stay always visible
The easier it is to use this method of using Wappler - to edit SC files directly - the more people will do it, and I imagine this is likely to increase the amount of support required, and goes against the way Wappler is presented as a no/low code producy. As others have said, you can see why the Wappler team don’t want to encourage this.
I often prefer to use an external editor anyway - I can open it on another monitor and the extra features are useful (I use UltraEdit mainly).
A solution I would find very useful would be an extra option on the right-click file menu to open the file in an external editor (which could be set in Options). Currently, I usually do this via the right-click menu: Show in Explorer, and then open the file from there - which is cumbersome.
Yes. I understand that.
But I mean a single short cut to show/hide the browser panel. Right now you have to check what panel you are in and remember the shortcut associated to it.
I’m suggesting a single shortcut to show/hide the browser panel independently of the section you are in(site manager, database manager, etc).
And then you could use that shortcut to open as it was the last time or use a section shortcut to go directly to it.
So now you have the following functionality:
1 shortcut to show/hide the browser panel as a whole.
1 shortcut for each section that will open the browser panel in that section if it was previously hidden or navigate to another section if browser panel is visible. But they will not longer hide the panel anymore.
It would make a much more consistent and easier way to navigate the browser panel.
I’ve been thinking about it. But thinking about it, I came to the conclusion that in the end it will not be very convenient, because it will make the interface less flexible. This will eventually lead to the fact that you will have to adjust the workflow to the interface, and this is not very good.
To combat the chaos in bookmarks, two excellent suggestions have already been made. The first thing that will improve the orientation of tabs is:
My opinion is that this can perfectly help with improving the orientation of open tabs. But I would like to make a note that it is very important that groups are created in advance and tabs are added to them automatically, then it will be effective. Otherwise, the actions to create and add a tab to a group will take so much time that users will avoid this process and the functionality will not work.
The second great suggestion is to improve tab navigation:
For this functionality, I have only one additional suggestion. Create internal tags that will combine the open tabs included in the group (this is very closely related to the first functionality). This works so that if you type in the search bar, for example, SC, then all the open server connect tabs will be visible.
Regarding the opening of the SC code representation, I am in favor. However, if it is not available, I will simply transfer the work with the code to VSC, since I often use it. In this case, Tom’s suggestion would be extremely helpful:
Let me first say, I know I sound like a broken record, and I know I sound unappreciative. For that I’m very sorry.
So with a big smile I say the following…
I know what you are doing is difficult.
I know you can never please everybody.
I know you guys are working your butts off.
I value the product and feel fortunate to be here.
I know the product has been improved enormously since I arrived.
All this and more is why I stay, And why I spend 8 hours a day in the editor.
Yet, I get frustrated every single day.
I’ll never suggest a bug reporting system again, but today I will be frustrated.
You say the product is very stable, but today I’ll be frustrated.
As far as I can tell, the three of you on the team do not spend 8 hours a day developing IN Wappler, you spend your time BUILDING Wappler. Your experience with the editor is very different from those of us actually using the tool and pushing its boundaries.
So, you have at least one customer that gets frustrated using your product.
I’ll leave it at that and go back to all that I love about Wappler.
I say the following…