This is really sad.
The Xojo IDE is ten years old and you’ve never used that button? It’s for adding stuff to the current project item.
That’s not true. When I was there we used laptops almost exclusively. I can’t speak to how anybody else used them, but some days I’d have it at my desk connected to my 27” display, other days I’d use it like an actual laptop.
FWIW, It’s a huge amount of work to make these types of changes to the IDE. It took over two years of work by multiple engineers to do it last time after the designs were done, and requires that other changes to the IDE largely come to a halt.
This may still get done, but personally I’d love to see Xojo hire someone trained in UI and UX to do the new designs so they don’t get themselves into trouble again. Preferably someone who has experience with IDEs.
yes, the crashes. See my “Debuggerhook” crash reports that I’ve been filing for several years now. This is infuriating and a major productivity killer on complex apps. Does not seem to be a priority as it has not been fixed, and dates back to RS even. Seems even more frequent with the latest Xojo running on my MacStudio/Ventura.
Agreed. Well, I’ve seen some projects growing more or less under the surface and hope that Geoff will incorporate one of those.
No doubt it was a lot of work: what baffles me is how the new design was deemed superior to warrant all that effort. My rule of thumb: empty space on a screen/window is never better. Basic concepts.
As you know Xojo Inc got plenty of feedback from users during the first betas for the Xojo IDE… Many of the things brought up here were brought up way back when…
Before things can get better, they have to understand HOW and WHY previous mistakes were made and why they were not recognized at the time…
Unless that self examination happens, things are not likely to improve even with more change.
It comes down to the division of space in the IDE. The debugger having its own tab in the RS IDE was a source of many problems. Every tab was a project item except the debugger, which lead to a boatload of special casing. And as we know, special cases lead to bugs. So we set a rule that the debugger had to move out of that system. The bottom drawer was the best we could come up with, despite our reservations about the lack of space.
Now, you might be thinking “well what about the run tab now” and that’s a fair point, but not that simple. It still only shows project items or an empty code editor. The full-tab debugger require(d) its own container with its own code editor, which caused hierarchy problems. Yes, the Real Studio IDE did it, but as I said, it was problematic. Some of the changes were motivated by making the code more maintainable.
The design of the IDE stems from a mockup I had done in my spare time. The RS IDE was looking dated and needed some modernization to stay relevant, so I was curious what I could come up with. The Xojo IDE we have now is similar to that mockup, but it was obvious there were problems. 2013r1 was just the first step because we needed to get something out. There was always supposed to be more.
I think the biggest mistake of the Xojo IDE is the handling of tabs. We wanted to mimic the browser experience, but there’s too many ways that gets violated. The VS Code tab experience is significantly better, and if I had my way, I’d copy that. There are definitely other improvements I’d like, but the tabs would be the top of my list.
Funny thing - you copy one thing, then you copy another, and here comes the lawsuit. So Xojo has to be different, almost by law, even if what is being copied is THE BEST solution, and sometimes/often there is only one best solution.
Also, my personal opinion about the IDE on laptops… the IDE should NOT take smaller screens into consideration, bigger screens should always be the primary concern. If it gets to the point where the one-or-the-other gets extreme, perhaps having (2) IDE’s, and Express one and an Advanced one would be a good idea.
And an admittance… I haven’t used the Filter field above the left side, and that has cost me dearly, scrolling excessively to get to different areas. I just discovered it - SHOOT
This is the way.
This is the way.
No, it’s Xojo…
As surprising as it seems, No, I never looked at it until yesterday or so… funny.
Also, since Xojo comic, a lot of features I used on the keyboard was lost (by me). Too many changes in a Row, maybe…
That was a fundamentally wrong premise imo. Not that it looked “dated”, necessarily (that’s subjective) but that it needed modernization, i.e. that sacrificing function for a more “modern” look would be good for users.
During a Xojo Zoom meetup sometime during Covid, I expressed my dissatisfaction with the lack of fixes to basic IDE functionality while unnecessary (imo and that of many others) changes to naming seemed to be taking priority. Geoff assured me that the IDE would have its day.
It needed modernization because old [looking] software doesn’t sell, and the RS IDE was far from perfect. We set out to solve problems, such as the tab hell users would often find themselves in. The Xojo IDE has a boatload of improvements saddled by some issues that never got resolved. Tabs and method signatures are probably the biggest of them.
I get it though, you want the RS IDE back. It’s not happening. IDEs don’t look like that anymore. The Xojo IDE can be improved / finished, but just complaining that it’s not the RS IDE is not helpful.
First she is not saying that IMO… What she is saying is that some very basic usability issues crept into the design apparently because form was seen as more important than function…
I may be wrong, but to this day I doubt there are many who used the RS IDE that would say they are more productive with the Xojo IDE… regardless of the improvements…
Another pet peeve of mine is that IMO screen space utilization in the Xojo IDE is not very efficient… Again form first function second.
I would have thought it would have been possible to make the IDE look more modern without introducing new usability issues (beyond getting used to a new IDE that is)…
Oh yes, this was better ! Now, we have a narrow area for method’s name and parameters and a huge grey useless area…