-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we fork VS Code? #458
Comments
Few questions:
2b) Have you shared this w/ them? Have other extensions author reported similar experience? (this is to gauge how common this is among other extensions)
|
Thanks for your thoughts on this @bclothier. 1... I am always trying to consider the bigger picture of cross platform, and with the extension also being cross platform in the future, having everything fully integrated into VS Code is quite a major factor in my decisions. Take the form designer as an example... it was no easy task to make that work efficiently in VS Code when the rendering has to be done out-of-process in the compiler process. It would have been a heck of a lot easier to have the compiler display a Windows form to do the editing, but then what would we do when we want a Linux or Mac based form designer? We'd have a lot of work to do in each environment to get something similar. The way it is implemented now (as an integrated webview with HTML/js) will simply just work when we move to Linux / Mac / whatever. 2... I don't recall the details of the first one. The one from last month was due to my error in passing a 'noDebug' flag to the VS Code debug API which had no meaningful effect in previous versions of VS Code, but suddenly in the last release stopped all breakpoints from working. I hold my hands up.... I am human :) 3... No, not at the moment. The extension needs some love (and an upgrade to TS rather than JS). 4... I would guess we'd have a public fork so that anyone can contribute, and we'd ensure that the fork can be used and installed independently from VS Code so as not to interfere with it (I believe the Code-OSS build process already does exactly that). |
I have no knowledge of VS code except what I need for TB. An IDE makes life comfortable, but only when what lies underneath works. Compiler and the necessary structures. |
I would suggest that having some coverage on the extension itself may be more instructive than getting a bunch of random opinions because then you can get data on how often VS code's updates impact the extension and in what ways. That may then help you determine how likely you will be negatively impacted by changes in VSCode and either make the case or argue against for forking. One aspect I did not consider is when you get to replicating the VB6 controls, will using a web browser make it difficult to do so? Would you need to be able to set up a traditional Windows host system with all the usual windows to support designing and manipulating VB6 controls? |
Its a good idea but I suggest no, or at least not yet, unless it turns out to be essential. You have a LOT of stuff to do and this is a potential distraction, or maybe somebody else could do it? |
@dmrvb This is not something I'm thinking of doing imminently :) There is a roadmap in place that will be followed. This is more of a general discussion about the possible future direction of the IDE and to discuss the pros/cons if we decided to go down that route. I wouldn't necessarily have to take the lead on such a project either. |
Is it worth considering Eclipse Theia? It's based on VSCode but designed to be even more extensible and modular. It supports menus out of the box I believe. Its not an IDE itself, but an open-source platform from which people can easily produce their own IDEs. I've not used it but it might be an easier path than creating a whole new fork. It claims to directly support many VSCode extensions, but I have no idea how easy (or otherwise!) it would be to get tB working there. |
@mansellan I have never heard of it... it sounds too good to be true! That is most definitely worth a look. |
In terms of API support, theia is currently working towards v1.55.2 of the vscode API (eclipse-theia/theia#9863)... in other words about 6 months behind. That's not too bad. By the time we get to look at this in more detail they will likely have the Testing API support in, and then there shouldn't be much stopping us trying out tB with theia and seeing how well they work together. Very interesting, thanks @mansellan The window/panel docking looks so much better and more configurable in theia. That is one thing that is really frustrating in vscode. |
Yeah I've been reading up on it. The lag is understandable given they're downstream of VSC, which is at best sorta-OSS* In your OP though you said that not being bleeding-edge with updates might actually be a plus. In terms of downsides, well it's dual-licensed against the Eclipse Public License and the GPL v2, both of which oblige one to submit patches to Theia (iiuc, not any extensions) back upstream. And its unclear whether it will have the longevity of VSC, as its more niche. May be best to keep VSC extension as an option, even if its less feature-rich. * terms and conditions apply A big plus though is that they fully endorse commercial use, including making available a pre-configured IDE for your customers. VSCode, the Product, explicitly forbids this, you would have to go to the VSC project (MIT) or VSCodium to do that. |
Theia looks interesting. |
Well, not really...what they do compel you to do (if I remember correctly), is to publish any changes to the original source code under the same license. But wouldn't contributing fixes, etc. back to the upstream project be the neighborly thing to do anyway? |
You're right of course, patches are not required by license. But they are a nice thing to give back, given you have to make your source available anyway. |
I am about to drop out of twinbasic again. I did never make the change from vb6 to vb.net for a reason: If you have developed this language already your team has the required tools and knowledge. Probably a bit lack of time as always since still so many things to do. But hey: VB6 lives a lot through its IDE, the visual designer and the tools that are working together. And it's independent from any 3rd-party tools. The developers that time did not have to accept any restrictions to theirs software nor any dictations of rules to follow what they will implement or not. The company had full control over what they might expose or hide and forged something, that i would say survived already the technology that kicked it from it's throne. even the effort its worth it to have full control and all strings together that you can pull. And give users the feeling of full control. if they are mighty: provide extensions for them who ask more. thats a lot to read. i know. i do not add any links, ask google - google knows everything, you will find the keywords. |
With the Access roadmap now saying that they want to support the Monaco editor - doesn't that open a potential window for using tB with Access ala VBA? But if so, would forking the VSCODE codebase now be a Good Idea(TM) now, or would it be better to wait for that Monaco work to get much closer to completion to try doing that? |
I came to realize why VS Code is so uncomfortable at first for the average VB6-er. It's because they are used to the default VB6 layout and because they never bother to customize it keeping code pane to the left and the 3 default palettes docked to the right. This is an awful layout that is never repeated in any other IDE starting with VS6 (the IDE for C/C++) and InterDev6 (the IDE for MS Java) and continuing to VS20xx (IDE for C#/VB.Net), Sublime Edit (IDE for everything) and come at VS Code (Sublime inspired IDE for everything) which all have the Project Explorer docked to the left with the editing pane kept to the right. This familiar layout of Windows Explorer (TreeView to left, ListView to the right) is not accidental. The idea is for the code you write (and profusely indent) to be as much in the center of the screen as possible. The text in the codepane is left-aligned (although I'm certain many VB6-er would like to center it like in MS Word:-)) and the left border of the codepane should not be furthest at the edge of the screen as is the case with the original VB6 layout. The first thing I do on a fresh VB6 setup is to dock every default pane to the left so naturally I felt no impedance transitioning to VS Code because everything seems normal, not completely reversed as is the case when you come from VB6 default layout. Just my $0.02 worth. |
I'd also like to know how much effect it has on those users transitioning from a MDI layout to a tabbed layout. IMPOV, tabbed => "ahh, finally I don't have to deal with moving windows around!" whereas others may go "how can I see 2 things side by side?!? I want my windows back!" Some re-training may be necessary to become productive in tabbed interface and thus regain the advantages of MDI with the tabbed interface. In the example of seeing things side by side, I wonder how many tried right-clicking the tab to use the |
My 2¢... VSCode reminds me of Emacs from 25+ years ago: requires learning a large minimum # of seemingly arcane things to barely get by; probably super-efficient once you become a power user (I'm not); feels overwhelming and awkward until you reach that point. (Speaking from general experience, not using tB in VSCode specifically). Also the adage "jack of all trades, master of none" comes to mind. Maybe this is unfair/unfounded. That said, since VSCode appears to have broad community support I assume there are good things in there and I will continue to give it the benefit of the doubt, and hope to learn it better. As for the tabbed interface, personally in VB6 I've long used an add-in to provide that functionality. (VBAdvance IIRC). Hopefully given how common that style is now, most VB6 converts will find it to be an improvement. |
For me it's better to have individual floating windows, not tabbed. The VB6 interface has it's own quirks and annoyances, no need to copy them. |
I took a little timeout to look closer at Theia. Initial impressions are good, and I feel this is the way forward. However, it is most definitely not a drop-in replacement for VS Code!... their API coverage for the VS Code API is good, but not complete. Several key features that tB uses are missing or incomplete, and so it would require quite a bit of work to get this going properly.
After a few hours of tweaking I did manage to get a tB project loaded in Theia... language server working, debugger (mostly) working, etc. Guesstimating, I'd say it would be 1-2 months work to get something reasonably polished and that's including some time for simplifying the UI to VBx standards, and adding the missing things that we can't get with vscode (like proper toolbars). Back to VS Code for the time being... |
That reads already good. I think its for Sure a netter was to have Control over what the Editor dies. Even If IT had some bugs - I would prefer this over a coding environment that is developed by a major software-company theirs policies and rules are not advantageous to the users. Not the rules written somewhere where you could read it.Not the rules that are officially published. You're a smart man, think a minute about it: why would a giant software company give away a coding environment as visual studio or vs code away for free since it was very costly to develop for sure... Why would they give anyone who wants to create some software the tools for it - even the one could develop something that could decrease the companies profit ... ? And why does this environment refuse to work after a while if it can not access the internet? All you type into that thing - it's not getting simply copied and saved. Hundreds of specialists are analyzing what is happening, not just for debugging purposes... It's less the inconvenient solution they are after, that's very rare. It's just the idea. If maybe Ford would give away their latest developed next gen dashcam to all other car-manufacturers for free- what would you think? |
@WaynePhillipsEA do you expect that these issues will become easier as Theia matures and catches up to VSC? Or will there be gaps to be patched for the foreseeable future? I guess Theia will always be playing catch-up, the question is whether it will reach a point where the newer features are not essential for twinBASIC. |
I support staying with VSCode. It seems a lot of people here seem to be a little anti vscode, probably because of coming from the actual VB6 IDE and I can totally understand that the change in concept can be quite a bit to handle. Using good old VB6 everything was a click away really, where vscode has a different "concept" in mind. VS Code's main use is really as a file based text editor with powerful commands which can be run via the command palette (Control/Command-Shift P) and you'll notice nowhere do they call it an IDE (Integrated Development Environment). It has been designed from the ground up to be used via keyboard first (shortcuts and command palette) and so that is probably why they are not too keen on adding UI elements like toolbars and menus which are extension specific. Having said all this, it can be a dream to work in if you accept it's design as is and fall in line (for want of a better phrase) to it's thinking. This might be a bit hard for people used to the Visual-Form-Edit first people who are used to thinking in that way, but I tell you the text editing part of vscode is miles ahead of VB6's text editor or honestly even VS2022. If you get used to working with multiple carets, folding of regions of code, all the good syntax highlighting stuff and it's powerful find and replace capabilities (among so many other features) you'll be laughing all the way to the bank. I also think that there are not that many developers these days which stick to only one technology or stack. I'd be surprised these days if a developer does not touch a little of html, javascript, css, markdown, powershell, bash etc... in their day to day work; and the fact that a lot of these technology stacks also use vscode is a really good reason to stay with it. That way you can do all your work in one place and not have to install and jump around from editor to editor. |
IMO to program with a text editor is far away from the concept of RAD development. |
As I started with VS Code I missed some stuff or didn't undersand how it works. I did have som success to create C#/net projects from console with tutorials. Now i can imagine, if I know the keystrokes, I and would know them in daily work, the keybord is much faster than mouse could ever be. Yes there is a learning curve. But I thinks it is worse starting. It seems VS-Code is written from (professional) programmers for (professional) programmers. |
I don't think it has to do with being a "professional" developer. Being "professional" in an IDE development would be to cover both, not only one. I think people are confused about that difficult to learn means professional. For me it means the opposite: unprofessional. |
Also bear in mind that the proposed replacement (Eclipse Theia) is forked from VS Code, and uses the same text editor. So it should be possible to get the best of both worlds - a familiar IDE with all the keyboard power VS Code too. it even runs the same extensions as VS Code, although the API lags a little so some of the extensions may have problems running their more recent versions. |
@WaynePhillipsEA I have been playing around with Flutter recently and they have used a slightly different approach to their dev utilities in vscode. They have these devtools which are opened in a separate tab which work with the currently running app. Also the way they make it easier is by using a button on the statusbar at the bottom... You'll notice they have a bunch of different tools which open in their own tabs and can be viewed while working. Also interesting is that they have the option to open these in a separate chrome window so that you could use them outside of the vscode window, but still linked to the running project. I'm not sure if this helps, but I thought maybe looking around at how others have solved the UI problem might give you interesting and different ideas. |
Closing this now that we're using a custom IDE instead (see #772 ) |
I must say that the more I try out the betas and play around with the new IDE, the more and more I miss vscode. I feel like using this stand alone editor is pretty much bringing about the same issues that I have with the original VB6 editor. It's closed and it does things in it's own way. I miss my extensions (there's a lot of ways to customize vscode and mould it to your own way of working) and the window management is not great in the new IDE. I also feel like you will probably spend a lot of time re-developing things in the new IDE which would probably already be working perfectly in vscode. Anyway, I'm not trying to be negative, but I think this decision might warrant more though or discussion... |
I agree with @mika76. |
VS is in my opinion just a temporary tool. They use it in Visual Studio as well and it becomes a pain on larger files and projects. Too slow for serious work. As more extensions you load in - as slower its get. By nature for sure. It can not be that difficult to write a fast usefil editor which can be enhanced by user need. Either by using COM or open the source. I am still happy with that wat VBA and VB6 offers - just adding MZ-TOOLS for code indenting and a few line operations. Simple, fast and handy - how it should be. Instead also to open a new cask of zensored concentrate on the compiler. I know that fiddling on the IDE is devs candy. But does not help at this stage. Same for GUI components. Happy new year to all :) |
I've toyed with this idea for a while now. You guys know I love VS Code very much, and its extensibility is frankly amazing. However, there are certain things that the VS Code team are not open to considering supporting such as proper customizable toolbars, and fully customizable menus, to name just a couple of them. There are also some things I'd love to do to make the transition from VB6/VBA more familiar for developers that are just impossible to implement as a VS Code extension.
Is it a mad idea to create our own fork of Code OSS and do whatever customizations we see fit? i.e. an official twinBASIC IDE?
It could be a maintenance nightmare. VS Code has major releases every month that introduce vast amounts of new features and bug fixes. Realistically, If we did fork it, we'd probably only be able to sync with the VS Code codebase every so often... perhaps annually. So we'd effectively miss out on the brand new VS Code features. But that may not be a bad thing either, as it allows the new features to mature before we look at using them for tB.
Also of note is that on two occasions the monthly update to VS Code broke something in tB that required me to make some adjustments and release tweaked versions of tB to match the changes in VS Code. So having a stable fork to work off would certainly help in this regard.
Enough from me... any thoughts?
The text was updated successfully, but these errors were encountered: