I think I already addressed your question previously
At this point Iâll get off the merry go round as weâve had this debate over & over & over & over and I just dont need to rehash it yet again
3 Likes
I donât want to refresh the debate. But I wanted to answer in a differential and correct wise. We could handle it not more different. You are inside of this situation and canât change what other people decide. What triggers me on it is that often it sounds a bit like: you have to look different on it while. And that is in my view not the case. I donât want to dicuss that either again but it was a proper reaction on your answer Norman. always when you answer like this you also try to show (maybe not on purpose and not with this target) that Xojo isnât that bad in the result. But it is.
Back to the discussion: they want to implement Github hat would make it less complex to work with it. Only thing is that Github can only work with the activated license while Xojo canât write text projects otherwise.
The use of a Github Client can also work, true but it is a big amount of manual work and the risk to forget about saving the changes. That can become a problem later when actualizing.
In this situation I would also like to ask: which GitHub clients are working with Xojo. I know only Github Desktop but, for example, is Gitkraken working in this situation or any other good client?
Iâm not trying to be an apologist and if I come across that wy then I havenât expressed myself very well
Is it the worst product I have ever used ? Absolutely not
COULD it be better ? Absolutely !
Are there aspects which need LOTS of love ? You bet - the IDE is definitely one
And most of the stuff in the newest parts of the framework
The oldest parts have few unknowns - still has bugs - but they are well known
Unfortunately this is also the code that has most likely been deprecated and will eve thrown out to focus on the new stuff that has lots of issues
The compiler ? Thats PROBABLY the most solid piece of everything (EXCEPT the android translator which has issues)
And âthe languageâ (basically if it works in XojoScript its âthe languageâ and everything else is frameworks)
It could use some modern additions like async await which I dont think can be done as an add on in a framework class
Am I happy with the state of things ? Hell no
But I DO have clients that use it so thats what I work unless theyâve approved me working on implementing their projects in other tools as a comparison.
Some have as they are interested, curious, cautious & making sure they have options.
I too have my doubts they will make much headway correcting any of these issues if they dont fix whats wrong
And whats wrong is not people or tools or skill sets
Much of it is process and NOT learning from the past and getting better by those learnings about how to do things better
Everything I know says that they have changed a few tools (moved to using git & the issues bug reporting tool) but still mostly work the same way they always did
Which means no required tests for code checked in, no peer review, and others
The process is busted. And so the product suffers because of that.
Fix the process and they might start to fix the issues.
But them doing nothing means the product will remain in the same state
And in a way that makes me feel sorry for them âŠ
SourceTree, Fork, GitHub Desktop are 3 I know work as I use(d) them all
The Discussion about the Bugfixing and process changes we had often enough I guess. And yes, I can see you have no chance to get out without loosing the paying customers what is not acceptable for you. I can understand that without any doubt.
Async waitâŠthreadingâŠyeah the are the needed things for programming. But we will not get them.
And no changes makes feeling sorry for them: true words and also sad words. I mean: tools like Java are running, C#, C++ also. So why they are not doing the best possible to get their tool running? Good question and we will never have an answer.
The Github Clients: which one is the best in your eyes?
1 Like
Perhaps it would be nice if Xojo would use it themselves. Nice for you, as it might increase the chances that they have time to deliver what are your top 5 priorities 
2 Likes
The low code definition of genius sounded for me like no code, or no anything, just weird. Donât shoot the messenger. But reading it again made me laugh tonight. Some cabaret interludes simply mature over time 
1 Like
thatâs called VScode, but âintegratedâ
1 Like
Gosh, thatâs truly hilarious!
1 Like
Well every git client would work in theory. But Xojo did change in the old days constantly many files which are not related to your code! So this easily ended in a mess. I think I can recall that they improved this ⊠but a git repository for other languages works a bit differently as everything is configured via text files (maven, gradle, npm, yarn, toml, yaml files) and for instance plugins will get loaded based on those information, thatâs not how Xojo works out of the box.
If I download a TS project in a (naked) IDE it will configure based on the GIT files whatever is needed for this particular project. With Xojo you are lucky if you wrote somewhere down what is needed, or you keep 10-20 Xojo installation in parallel, or you sync dylib with github (which is madness and will cost over time additional money). Quite funny that Xojo people are complaining about electron apps being too large
For the git clients? Why a client ⊠console is sufficient - but the software you want to âgitâ has to be designed for it. 99 percent in 2023 are designed to work together with git âŠ
Compared to what other IDEs offer today and what is state of the art, the Xojo approach is the poor manâs VCS.
1 Like
https://www.git-tower.com/ (if you want to remember that you are German)
and GitKraken
IMHO best VSC integration.
Fork is still somehow my favorite indeed. Probably because I like the idea to support a devoted young couple producing a fantastic tool.
But none of them are ânativeâ
2 Likes
Thatâs the problem with the Git integration. Possibly Norman didnât saw this problem or he is not realizing the size of it or he does not want to discuss that. It is not only the integration of Github to have the code secured, that I can do with Github Desktop and Text projects. But. At the end of the Story I have nothing than my Surcecode. no settings, no additional Files, no Plugins. Everything I want to or letâs say have to integrate and to setup to get the project running I have to note manually so I can do that setup later.
Thatâs the difference to all languages I know which are supported by Jetbrains IDE and its Github Integration. Looking oni there should also be something like Gradle or Maven as a Service for Xojo to have all configurations in am automation. But, letâs say, that may integrate Github in that form that the source code is stored. Nothing else.
And that was also the Answer I wanted to read. Every client could do the Job but you will never have even 10% of the power of a real modern IDE with its Github integration.
1 Like
IMHO, one of the major problems with the current framework is that it is developed in a different tool and doesnât use Xojo code. It is a bloated piece of junk that is holding Xojo back (mainly the CEO is). I believe that the framework could be replaced with classes that use declares to access system API. If your application doesnât use the Folderitem, it doesnât get included.
Bloated apps are bad. They waste time and bandwidth being downloaded, they waste performance when being checked by Malware/security API, they waste CPUTime and SSD life span when being loaded into memory, they waste memory with junk that isnât needed.
A helper I converted to Objective-C can return the result, before the Xojo version has even finished being checked by GateKeeper and loaded into memory.
At this point, I am looking forward to getting away from Geoffâs idea of what Mac apps should be like and closer to what I think they should be like.
I wish they would stop lying. I can prove in a few minutes how Xojo is the opposite of low code, especially when they ignore your request to add support for a tiny function thatâs already present in the system and you must then write a ton of code to replace the entire wheel, before you can replace the value cap.
3 Likes
VS code isnt what I had in mind
I can still manage with BBEdit, emacs and a cmd line in terminal
is it what I prefer ?
no
but if someone said âthis is th tool set you get oh and weâll pay you well tooâ Iâd be in
Iâve done that before and written code in forth (20+ years ago) where no IDE was the standard
Do I WANT got go do that again ?
No
but if someone paid me that kind of money again Iâd be in
that was one of the reasons for the Xojo framework which got shot down becauee âit was too verboseâ
OK so NOT verbose and bloated
And there is some stuff that will get included simply because it exists in other classes
Even if you NEVER use a Folderitem in your code, the Application class has a property that uses this type so it gets included either way. There are many interdependencies like this
Which while a single example illustrates the problem. The compiler should be smart enough to know if the folderitem is being used or not, rather than just including it because thereâs a property or method that uses it (while the customers code doesnât).
Lets take the movie player for example and thatâs a less used object, but is present in every single Xojo made application. It doesnât need to be there UNLESS it is needed. To be honest, if you want a movie player for the Mac, you may want the actual Quicktime player, not the custom Xojo one, but doesnât matter as youâre getting it regardless.
Just like adding introspection forces everything to be present, it shouldnât need to do so, only what is actually needed.
But at this point, weâre just ranting, because Geoff doesnât care about quality, performance or even retaining customers.
2 Likes
Anyhow, as long as bug reports are closed based on âbelievesâ instead of solid testing and evidence, there is no way Xojo will become any better.
2 Likes
and while Xojo might be trying to improve, Microsoft is including Python into Excel ⊠Bye, bye office automation via Xojo âŠ
1 Like
Wow. That blog post gave me a good chuckle.
In theory yes - but TBH I have no idea how hard the sort of analysis is to do or what the compiler person might need to do to make this happen this way
Yes. This was, in part, the motivation for the Xojo framework which made much more extensive use of namespaces
Xojo currently CAN strip a unused class or module
But, the way the framework is, it doesnt because EVERYTHING IS GLOBAL
The Xojo framework can be stripped better because it doesnt have everything as global
But, theyâve decided to move away from that, back to everything global, and clobber users code every time they add something to that global name space
In the Xojo framework even if they added something it would NOT clobber youâre code - because it WAS in a namespace
Oh well
Introspection can only introspect what IS present - it doeskin add things that arent present in any way. So if you didnt use a certain class then introspection wont cause it to be added
BUT you DO have to be careful HOW you use introspection - as its use CAN impose a requirement that a class be included. The example on
https://documentation.xojo.com/api/language/introspection.html#introspection
for âââIntrospection â Xojo documentationâââ is a good example of how using introspection can force the compiler to include classes you maybe DIDNT want included
Sadly