I believe you. But as someone else pointed out, that doesn’t mean it’s usable for the rest of us and our projects.
[quote=14370:@Norman Palardy]well crap
it showed as being posted twice here so I deleted the second one - which apparently nuked both :([/quote]
That’s probably a bug in the forum. I wrote an answer and saw it duplicate a moment ago. I decided to refresh just in case and the duplicate disappeared.
And that there’s a difference between “cannot” and “will not”
I dont get a choice
I’m sure there are many others out there, like myself, who are using Xojo IDE just fine for real projects. Would I like some things to be different? Yes, and I filed bug/feature requests as well as signed my support onto some others that I feel are important. Am I unproductive? By no means. Maybe I am a slow thinker, but most of my coding time is spent planning through things, designing, etc… The amount of time that Xojo costs me in areas that I think could be better is extremely minimal.
Are you using Tabs efficiently? Do you use the Goto feature? Do you use the filter? What about clicking on the library and just start typing the name of the widget you want, then pressing enter, etc…
Hi Joe
I like your answers (yours too Norman). You both identify the issues as I expect that you would, being experts with the product.
So binary components are not going to be easy and therefore extending the IDE is not going to be easy for ‘external’ developers unless you arrive at a fixed ABI although I am guessing that the ABI would only change across major versions and so would just require anyone with binary components to recompile and release in line with a major version change. However if binary components is going to be difficult then maybe just consider standardising the language and project files and providing a way to automate compilation (a stand alone compiler or a command line for the Xojo application). Then developers can use some of their own tools to do the coding and use Xojo for the compilation, debugging and most probably the UI part of the application.
I don’t know if you are familiar with it but this is how the RubyMotion system works where you can use XCode for nib files or code UIs by hand, GDB for debugging (and LLVM for compilation). The JetBrains people have incorporated RubyMotion into their cross platfoem RubyMine IDE. I know it is not quite the same scenario as Xojo because RubyMotion is OS X and iOS specific, but the similarity is in the use of components. It would only need RubyMotion to abstract away the cross platform parts (no easy task and this is where Xojo wins) and the two would be very similar but that is not going to happen anytime soon if ever.
[quote]And that there’s a difference between “cannot” and “will not” -
I dont get a choice[/quote] - Norman Palardy
Right. I moved back to RB2012 last week because I wanted to get the project done. I don’t know about everyone else but the end is the least fun for me. Having even minor inconveniences was just too much. That said, I could have continued to use Xojo.
I’m going to chop your reply up in all sorts of ways so that things flow better.
Depends what sort of extendability you’re specifically looking for. For example, it’s theoretically possible that we could allow sandboxed extension of the IDE with XojoScript.
Well, define “major versions”. In a normal year, we aim to ship three to four releases. Convincing third parties to recompile and release yet another version of their product that often is something I don’t think is going to happen. Even if they’re willing, imagine it from an end user’s point of view: they have to know which bit to download.
You’re asking for three things here:
- a language specification
- documentation on our file format
- a command line compiler
You should file Feedback reports for the first two and sign onto case #3215 (“Allow compilation from the command line”).
What you’re getting sounds like the development of a third party IDE, which is more of a business matter and not a technical one. I’m not qualified to give you any answer, opinion, or comment on this.
Editing “text” in an external editor actually doesn’t get you what you think it does.
The IDE itself actually generates a LOT of code for you when you hit compile / run.
Lose the IDE & you lose that generated code & you can’t get the compiled output you expect.
The IDE & compiler work hand in hand.
At present you can’t have a “stand alone compiler” with out the IDE
Thats not to say it won’t ever happen (I think this one is on the list of most requested items) but at present it can’t
[quote=14430:@Joe Ranieri]I’m going to chop your reply up in all sorts of ways so that things flow better.
You’re asking for three things here:
- a language specification
- documentation on our file format
- a command line compiler
You should file Feedback reports for the first two and sign onto case #3215 (“Allow compilation from the command line”).
[/quote]
I feel duly chopped 
My Top Cases are:
- Allow compilation using command line (Ranked overall 6th - Steve Fyfe created 2nd July 2008)
- Provide “All Code” View in IDE (Ranked overall 10th - Kelsey McClanahan created 10 April 2009)
Hmmm - I get your point - I think it will be quicker for me to work it out for myself 
Oddly enough #2 is easier to do than #1
[quote=14435:@Carl Clarke]My Top Cases are:
- Allow compilation using command line (Ranked overall 6th - Steve Fyfe created 2nd July 2008)
- Provide “All Code” View in IDE (Ranked overall 10th - Kelsey McClanahan created 10 April 2009)
[/quote]
I do think that Xojo should make an official ruling on issues that are on the Top 20 for multiple years. They should say if they are going to do it or not and given a reasonable guess as to when they will get to it. If it is going to be a long time coming, then the issue should be marked as an honorary top 20 and give people back their points to use on other issues that are more likely to get done. Some people have had their points tied up in the Top 20 since 2008.
I’m not sure I understand why we can’t have a command line argument to the IDE that specifies an IDE script to run. The IDE would open, run the script, and then close. That would do 99.9% of what I want. Is that very difficult? (Honest question, I don’t pretend to know the answer.) Oh, and what ever happened to the little IDE scripting utility from way back when. I could never get it to work, but it would also be a mechanism to allow automated builds.
[quote=14431:@Norman Palardy]Editing “text” in an external editor actually doesn’t get you what you think it does.
The IDE itself actually generates a LOT of code for you when you hit compile / run.
Lose the IDE & you lose that generated code & you can’t get the compiled output you expect.
The IDE & compiler work hand in hand.
At present you can’t have a “stand alone compiler” with out the IDE
Thats not to say it won’t ever happen (I think this one is on the list of most requested items) but at present it can’t[/quote]
It would suffice to be able to do somethings along the lines of
Xojo -project<projectfile> -analyse -outputfile<outputfile>
Xojo -project<projectfile> -compile -rundebug
Xojo -project<projectfile> -compile -runremote<configname>
Xojo -project<projectfile> -buildTargetsThat way we can still keep the LOTS of generated code, it can’t be so hard to fire up those UI events to do that from a command parameters can it? Xojo already fires up from project file association so it is half way there today.
I believe this is doable today with IDE scripting over IPC. It all still works and has actually gotten slightly better in 2013r1.
The thing people want from an actual command line compiler is not to have the IDE running. The IDE requires that there be a GUI login session, which isn’t really ideal for build bots and other deployment scenarios.
It’s not quite a “command line compiler” and WOULD require a logged in user session to be possible
Never noticed that the utility is missing from the install
However an old version should run just fine - and yes it does let you more or less achieve what you asked
[quote=14426:@Norman Palardy]And that there’s a difference between “cannot” and “will not”
I dont get a choice[/quote]
I “cannot” use it if the cost in time breaks the project budget.
Now can we drop the semantics debate?
Norman, the bottom line is you got a bunch of RS programmers they say they can’t work as productively in Xojo as they could in the previous generation product. I think you have a couple of iterations to fully understand this issue and fix it, or you are going to see programmers leaving in droves or sticking with RS. We want Xojo to succeed, but you have a big problem with the Navigator, and a bunch of little problems scattered elsewhere that make it unusable / slower / no fun / not as productive…take your pick.
You want an easy place to start? get rid of that ridiculous chisled font in the Navigator. It looks neat for about 5 minutes until you realize you will be staring at it 8 hours a day. There’s a reason they don’t print books in fonts like that. Same logic applies.
You know, when you lead a mass exodus and nobody follows, you look pretty silly to all involved. I think you’re overstating the level of dissatisfaction by an order of 10. You’re really better off turning the frown upside-down and trying to make Xojo work for you. There are plenty of things to want better in this product, but wanting to go back to the old IDE is an absolute non-starter.
[quote=14464:@Melvyn Pate]
You want an easy place to start? get rid of that ridiculous chisled font in the Navigator. It looks neat for about 5 minutes until you realize you will be staring at it 8 hours a day. There’s a reason they don’t print books in fonts like that. Same logic applies.[/quote]
That ones already done 
You think I’m the only one talking like this? I’ve had access to it for 4 months and I can’t work productively in it, and I’ve tried really hard. If it works for you, great, but a bunch silly cliche’s like turning my frowny face upside down, isn’t fixing the issues. And who said anything about wanting to go back to the old IDE? None of us want to do that. But given the choice being 25% more productive in RS, trudging through Xojo, or moving to another product, take a wild guess which option it isn’t going to be?
And I’m not leading anyone or encouraging anyone to move on, quit speaking for me. I’m making an observation that if the issues aren’t resolved, people are not going to continue to working a programming environment that they say is significantly worse than the previous generation of the tool, just because the Xojo programmers can. Not happening, IMO.
Again, I hope they get things fixed and I’m a happy programmer in Xojo. But if they don’t, you’re absolutely naive to think that I’m the only walking away from it.