That’s why I decided today to not renew my Enterprise license. Will take another look at it 2 more iterations down the road, but as it is now, huge time sink for me to use. As I said, enjoy the new IDE.
i am beginning to fall into melvyn’s category. there have been changes in the IDE for the wrong reasons. it seems like it was decided to make it pretty not productive. i need a high performance tool, not an iPad app. the inspector layout (i believe it’s been changed back so you don’t have to scroll endlessly), the library (i’m sorry. i can’t tell which three buttons at the top are which by looking at them (as i am writing this, i just realized the fourth icon is the bevel button. not good). the old control list was better and took less space and i didn’t need a search function to find anything), control sets instead of plain old index where i just had to type a zero to make a control array, not to mention that now to get to the control in the contents list, i have to drill down three levels. also search selected text in find and replace is gone. i won’t even mention the project filename extension.
these are the things that drive people crazy. i can’t think of rational valid reason why they would be changed from the old IDE. if there is, i open to gaining some understanding.
to be honest, i do find somethings better like the keyboard shortcuts, except you took out the F5 key for running the program. i do understand there are some structural things that are much improved and that there is a better path going forward. the new layout is fine.
pardon the frustration, but i have many hundreds of hours of coding time invested in this product and i want to see it succeed. i just don’t know what to expect now. R1.1? fixed interface and fewer bugs? when? do i need to wait for R1.2?
If you click the gear in the Library pane (bottom left) and change the view to “Small Icons And Labels”, you get more or less the view of the old control list.
[quote=14190:@Norman Palardy]Really ?
Beyond that it’s not as comfortable as the old IDE - but recall the old IDE has had 7 years of bake time to get to where it is.
I recall how rough it was initially. I stayed using 5.5 for about 2 years after the new IDE came out.
[/quote]
To me it seems RS is inventing the deep plate once more and we have to wait 2 - 7 years before we can use Xojo smoothly, and in the mean time our non related IDE bugs won’t be solved for a long long time.
And when Xojo finally works (7 years later) RS get bored and want to play with new technology. Then we repeat the steps above.
Same time lot of high expectation was raised about 64bit and LLVM from RS. Oh No RS gonna give you a new IDE first which not really gonna improve our business.
Would you buy a car if you knew it will take couple of years before you can drive from A to B comfortably ?
Having written software commercially for most of my adult life I have great respect and sympathy for the creators of Xojo. Xojo and its predecessors are great development products. The BASIC derived language is perfectly respectable to those who have a sound and sane opinion. I am not a Xojo Basher in any sense but I can see the problems, now we should focus on the solutions!
I can’t help feeling that a good way forward is to be more open (not just about the problems as Norman has been) but about the product; specifically the specification of the language, the ‘source’ files and providing an extensible IDE. That way the users (developers) could begin to address the deficiencies rather than just pile up problems on Xojo who’s resources are obviously already sufficiently consumed.
Like:
IDE Plug-ins (Add-ins) that can hook into the IDE and can display/create/modify the project’s resources in different ways?
External tools that can display/check/create code and resources?
Command line compilation?
Debugging hooks (in IDE and/or external) Like the remote debugger specification?
Then we, the users, can create our own solutions where we feel that the problems exist. A the moment all we can do is highlight issues and either wait for a solution or be informed (directly or derived by inaction) that there is not enough ‘need’ to justify a new feature or not enough resource to create it. (Or get fobbed off my a 'It’s not the Xojo Way" kind of answer).
You don’t have to Open Source (always seemed crazy to me but companies still make a lot of money and the users feel a sense of controlling their own destiny) but at least have open specifications, APIs and standards so we can enhance and extend Xojo in the fullest sense rather than just the compiled result sense.
Turn your users (developers) into an team of Xojo developers who can help develop the product as well as use it to develop solutions for their customers? There is a thought, Xojo could become so diverse and popular that… Apple iOS apps… Excel Spreadsheets… Ruby DSLs… you just need a solid extensible core.
Paul, thank you. I did look for this option, but couldn’t find it… It’s not obvious from a design stand point. i would have put the gear at the top where you would most likely associate it with the library.
you are right it should be at the top
I agree whole heartedly. But this isn’t happening in a 3 month period, it is going to take several versions to get things right. As Norman said, he stayed with 5.5 for 2 years before switching. In the interim, many of us still have to make a living or produce products. I can’t just switch over to Xojo while they work out the issues over the next 6-18 months. That is why there is a need for a couple of Real Studio patches with some bug fixes, no new features. It’s a fairly common thing to do in the software world. For most products, the entire user base can’t switch on a dime.
I think what set me off was the one word answer to the chances of such a thing: “Zero”. How about a litttle context? How about thinking about the position many of us are in and talking about it for a while? I am sure the idea was nixed at some point in the past, but I am guessing that was before the release and the productivity problems people are reporting this week.
I know things are going to improve, but it isn’t going to happen overnight. A couple of point releases for RS isn’t going to set Xojo back. You guys are always saying how “this doesn’t affect that” when talking about why something isn’t getting done, so don’t fall back on the line that a couple of RS service packs are going to wreck the whole Xojo schedule.
[quote=14283:@Melvyn Pate]
I think what set me off was the one word answer to the chances of such a thing: “Zero”. How about a litttle context? How about thinking about the position many of us are in and talking about it for a while? [/quote]
There is NO chance of a “Classic Coke” release.
Why ? The frameworks have diverged enough in getting Xojo to be a Cocoa application that trying to roll bugs fixes back to that branch simply is not possible. We’ve restructured & revamped the frameworks anough that 2012r1 and r2.1 were the last of their species.
Getting those ready took us a long while to achieve as we had to literally port fixes from the updated frameworks back to 2012 to do that.
And we knew that at the time and have moved on with updating the frameworks so that we could move Cocoa ahead.
I’d say there is virtually zero chance a Classic release can happen.
You are right that improvements and fixes will take time, I was trying to propose a fundamental change in the thinking so that history doesn’t repeat over the next few years by suggesting that they open things up a little more to give the developers new options. Compilers can (and are) thoroughly tested, the same for frameworks and libraries. UI testing is a bit more tricky and UIs themselves are always subject to opinions. Because the whole Xojo ‘thing’ is integrated it can all fall apart (as does happen when there are changes) requiring a whole new Xojo ‘thing’ to be fixed and released. It is not the same situation with most other languages where IDEs. code, compiler, frameworks and libraries are separate and somewhat replaceable components. Xojo/RS/RB is still looking too much like Microsoft VB of the old days in respect of everything being too integrated (even VB was a bit more open). That is why for example when people ask for SCM solutions they are given the suggestion of using text projects and external SCM tools and in your case, you can’t use the new IDE to target previous versions and Xojo can’t simply supply a patch to a library as they have to create and supply a whole new Xojo ‘thing’.
Yeah I had that kind of unhelpful response. I can’t decide how to take it. I am sure that some people are a bit stressed with the changes and issues but alternatively it can easily look like arrogance and a lack of respect for the poster’s intelligence/view/experience.
Lets face it - most people capable of developing software are going to be pretty smart people - I never underestimate my fellow developers nowadays but I was guilty of that too when I was less experienced in the wider sense rather than the youthful sense.
I am prepared for my ideas to be easily dismissed even though I know that they are sound ones. There are some huge languages out there with libraries, frameworks and IDEs all working in a similar way, so in fact ‘my’ ideas are really recognition of the ideas of many other smarter people.
I still remember the IBM MCA bus vs. ISA bus and how it essentially lost IBM its large PC hardware market share. Wikipedia article for those too young to remember. Betamax vs. VHS? IBM Presentation Manager vs. Windows? Technology History has shown that it is difficult to force your users down some paths unless you get it about 100% right like Apple do and you have the resources to tide you through when you get it wrong (like Apple do). I don’t believe that Xojo is wrong enough for a disaster like MCA/Betamax/PM to occur but you could make more stable by providing more options like for example an IDE that was capable of targeting some older releases? Like a standalone compiler and linker working on standard source code and libraries? I appreciate it is too late for Xojo R1 but it deserves some thought.
Norman, what is it they say? - “I feel you”. I just want to try to expand the thought that goes into things a little wider. I know that you are were you are with Xojo and it is still a great product - it just could be so much better and stronger if it was more open. I doubt if you would lose one customer by opening things up and I expect that you would gain many thousands of new ones. The idea of one set of source code for Mac/Windows/Linux without Java or Mono hacks is sweet enough, add the iOS/Android and maybe Windows Mobile and you have a world beater. And all you need is the language, compiler and libraries that you already have (ok not for mobile yet). Sure, provide an (extensible) IDE but why bind them together? Build the licensing into the language translator, compiler and libraries if that is the problem?
If the IDE is written in Xojo and Xojo can call external libraries then can’t Xojo be made to produce external libraries that can be called? I appreciate that you may not want to produce the standard dynamic library format for Mac/Win/Linux but you can make your own Xojo format, I know it sounds easy if you say it fast but it is just a jump to execute code in a memory location in some binary that you load. Oh my - soon your developers would be creating binary components for reuse/resale instead of encrypted Xojo source code modules - am I dreaming too much?
I remain an admirer of Xojo, I wouldn’t spend so much time thinking about it and writing in this forum if I wasn’t.
Personally I fear that Xojo becomes really usable in about one or two years. Then hopefully supporting iOS AND (more important) Android. We’ll see. But I’m glad to find that I’m not the only person who is unhappy with the new Xojo IDE.
Norman, your post 14313 was deleted? Why? The communication was good.
Looks like I was communicating with myself now 
The problem has never been that we don’t want to produce native shared libraries, it’s been that there is a major dependence on the generated code and the framework. Plus we don’t currently have linkers capable of doing this.
As for not having a custom format, it’s partially due to having no fixed internal ABI. The current situation lets us improve the runtime structures and optimize memory usage and speed without breaking code. Once we commit to a stable ABI, things become more rigid and some things impossible (without breaking compatibility). There’s a few other issues, but this is the major one that pops into mind.
As for being just a jump, that’s not really true even for native shared libraries. You need to do relocations and generate position independent code.
[quote=14339:@Carl Clarke]Norman, your post 14313 was deleted? Why? The communication was good.
Looks like I was communicating with myself now :-([/quote]
well crap
it showed as being posted twice here so I deleted the second one - which apparently nuked both
To some degree, it must look look like we’re resistant to any outside suggestion. It’s more that there a lot of technical issues that get in the way of things. Also, a policy of not ever talking about unannounced future plans doesn’t help much (but it’s a good policy!).
For example, one of the really common requests is pre-emptive threading. It’s a challenge designing something like this in such a way that limits your ability to shoot yourself in the foot and also doesn’t involve locks everywhere. Raw pre-emptive threading is hard, even from languages that expose it directly.
There’s also the issue that our framework, which originated from a much simpler time, assumes that there is one and only one user thread running. It is very much not pre-emptive thread safe and doing an audit of the entire codebase would be quite the error-prone undertaking.
From a user’s perspective, we’re being resistant to change and are ignoring one of the top Feedback requests. Internally there’s been a lot of thought, proposals, and discussion put into it by former and current people at Real/Xojo.
I’m not using the term “usable” in the sense that the project won’t open or compile. I’m using it in the sense of being able to actually navigate, manage, and work with large projects all day long. My line is not “can it be done”, but “can it be done with productivity and comfort comparable to the previous version and/or other IDEs.” Understand that Xojo went from being my most comfortable and productive IDE to being something I feel like I’m fighting with. Also understand that productivity was one of two major Xojo advantages to me, one of the two big reasons why I would recommend it over Xcode, .NET, whatever. (The other being cross platform.)
I’m not trying to step on your toes. I know you guys worked hard on this. From what I can see the code base is a solid one. That’s why I said I don’t think anything is “fundamentally broken.” I’m just expressing frustration and concern because without a few important revisions I feel I cannot use the new IDE. I can’t work all day and feel like I’m fighting with the IDE when I need to be focused on my own code. And I don’t want to be sitting here in a year still using RS2012, or feeling frustrated with Xojo, or possibly choosing .NET instead, because I like your product.
There’s also the tiny issue that release quality Cocoa is bound to the new IDE. You mention that you stayed with 5.5. for 2 years. But that’s not really an option for Mac projects this time.
I don’t think the UI needs leaps and bounds to go from frustrating to at least being comparable to the old in terms of usability and comfort.
[quote]Patience.
It’s been out 10 days :P[/quote]
This is like telling a kid “patience…I’ve almost got the toy built” 10 days after Christmas 
I work on the IDE using the IDE so yes … really I can.
I get that its not the same as the old IDE - but it’s not “unusable” thats what I do all day every day 15 hours a day.
I wish this were just a kids toy at Christmas. We’d already be making pies in the easy bake oven, riding the bike & playing with the train sets all while barnstorming the town with our RC helicopter (and maybe have the robot trashing the city)