While I know I’m opening a can of worms here, and we do have our own internal roadmap of “this has to come before that,” I’m wondering if there’s anything that you guys wish that Buoy did natively that it doesn’t today. For instance, Crypto and better Regular Expression support is already planned. TCP, UDP and IPC sockets are planned. Toolbars are coming. Björn asked for a full plugin SDK.
But if there are other standard-ish items that you feel like are missing, let’s talk. We reserve the right to say yea or nay, or suggest that it be released as a user-contributed package, but take this opportunity to possibly guide this early development while you can.
I sort of mean for when I start connecting my Image processing libraries. As in how I would access pixels for reading, and how I would make new image.
Normally I convert Image to RawBitmap object (which is optimized object for image manipulations and is same on all platforms). Then I would process one or multiple effects and things on the RawBitmap. Then when the user wants to say display on the screen then Picture would be generated from the RawBitmap. (often maybe at just low display resolution if we talking about huge image).
So basically reading and making new. (writing not needed).
I also have small touch point with images in the Word component but I think I just skip that for now to let everything mature a bit first.
If I would have to answer for a whishlist: an IDE like XoJo while this is something the former CB6 users will want to get. But I guess you arer on a good way for this.
We have a way to go before there’s an IDE. Right now we have a chicken and egg problem. No visual editor makes it hard to layout apps. That’s why we’re doing a layout editor as a sample project. VSCode actually provides a ton of what an IDE does already, including things that Xojo devs were asking for, like git integration and watchpoints.
To be honest, after having used the Xojo/real IDEs for the last 28 years, I too am struggling with wrapping my head around VSCode development but it is starting to grow on me. This is actually part of the reason that I’ve been putting so much work into getting the experience to be as good as it possibly can be. I mean right now, you can open a project, press F5 and debug your app, including breakpoints, watchpoints and a stack.
I think the best answer I can give you is that as long as this is a totally non-profit hobby project, an IDE is probably off the table. My instinct is that it could take 6-12 months to build and without some $$$ attached to it, I’d get bored really fast.
If anyone wants to help in that regard, you could always buy me a coffee.
I just hope that if IDE is made that almost nothing gets inspired by Xojo.
The IDE was whole reason why it was hard or impossible to show it to real developers. The entering methods into different fields and what not that was just dead end to show it to real developers.
I encountered this the first time back when I was in the University when it had just transitioned from CrossBasic where I made the mistake to give speech about it there. And I more or less had lost the audience right at start when they saw the IDE. (Ever after that if showing people something I made sure to show them the IDE last so they would maybe be at least a little intrigued by something else before they would write it totally off)
There are ways to accommodate people though without gimping it down. Some IDEs have had methods listed in list like X does, and have had “New method” that brings up window with fields like X does.
There is nothing saying you cannot do that, the big mistake is to force it. Since having all that is just navigation around free text things.
Having only a single way to do things was OK for newbies but areal hinderance to experienced users
It OK when you start out then after a while you want to just type in all the code & use it as is
I have this problem with every language which has no UI editor. You can see that many people dare not starting to develop in this languages. For me it makes no difference. Coding with JavaFX or coding with Java Swing isn’t any kind of problem. But I could also use Java Swing Matisse UI editor or Java FX SceneBuilder as editor.
So I guess it would be interesting if the ui editor you deliver is working in a project without bigger problems. It does not have to be IDE build in. And your decision for VS code: I really understand what you mean cause this editor is extremely comfortable and acts as an IDE. And this job it does well. But people from xojo environment are used to have much comfort. that#s why i meant that.
the way you are going is a good one. And I am really interested how this development will end up.
Yeah the first time I saw this “form first” approach I thought, why would anyone want that. Unless maybe you cut your programming teeth on it and know nothing else. The only reason I’m interested is the multi platform targeting from a single code base, that’s the compelling value proposition when it’s not done haphazardly with false starts and poor support like X.
What I’d really want is a round-trip, “code to visual layout and back” thing like WinForms, where you switch between visual and code editing views where and when it makes sense.
In principle nothing would prevent someone from making an alternative dev environment like that even for Xojo given the GitHub-friendly solution format. It’s just that with their sun setting and users fleeing, there’d be no point. And IIRC their lack of a clean, supported way to do command-line compilation would make full integration difficult.
In WinForms the default arrangment is a form, call it MyForm, and that is represented as MyForm.cs which is a partial class. There’s a designer generated file, MyForm.Designer.cs, that defines the controls and positioning in the designer, which is the rest of the partial class. That’s segregated as it’s not intended to be hand-edited and that’s stuff the designer controls. MyForm.cs is going to receive all the event handler code stubs inserted by the designer and you can either put support methods for the form in there or have them elsewhere. If you click on the event in the property sheet for a control it just takes you to the code editor with it positioned on the inserted event handler stub. Event wireup is done for you in the designer.cs file.
If you are in the designer and you decide you want to hook up an event you do so and it inserts the event handler stub into MyForm.cs. Or if you define it yourself then the designer is aware of it, etc etc.
It’s not the only possible exact way to do it but it’s one way that works well in my experience.
(As an aside, when it comes to designers and any sort of generated code, partial classes are your friend and should be supported).
