ARGEN is now open source

Targets Web
22

Hi. I appreciate your plugins :wink: Many moons ago Iā€™ve created an interesting test tool thanks to your java plugin. But there is something dangerous in using closed-source code in an open-source projectā€¦

1 Like
23

While it IS easy to remove the MBS dependancies, converting back to API 1 for 2019r1.1 not so muchā€¦

I changed the Vars to DIMs , DateTimes to Dates , and SearchFields to TextFieldsā€¦ And it seems to run fine in 2021r1.1ā€¦

In 2019R1.1 it complies and starts up the IDE just fine ā€¦ but when I chose a DB type and an SQLite DB file, after connecting I get a NOE in winNaming.Display on the line:

txtNamespace.Text = moProj.DataClass.sNamespace

As it compiles in BOTH 2019.r1.1 AND in 2021r1.1 the code should be valid API 1 code, how can I only get a NOE when I run in 2019r1.1?

At first I thought it might be an index thingā€¦ but I did not change anything from API 2 to API 1 where that should matter as teh methods that use different starting indices have different names in the APIs AFAIKā€¦

-Karen

24

It was not originally intended to be open sourceā€¦ but that is fairly easily dealt with.

25

Yes, I know. But now that the program has been made open-source thanks to the decision of the rights holders, it will be problematic in the long run to maintain closed dependencies.

I just removed NSColorMBS. Iā€™m not sure about the rest, donā€™t want to broke something.

And because of a few yearā€™s pause from Xojo, I donā€™t understand API 1/API 2 change yet, sorry but I canā€™t help.

26

All of the MBS stuff is for mac specific UI stuffā€¦ I just commented out the mac specific code and had the methods return what it would for Windows on the Macā€¦ and it all works.

It personally does not matter to me if the UI does not look 100% ā€œrightā€ on the Macā€¦ Iā€™m not selling ARGEN, just using it!

BTW I do have a recent version of the Einhugur plugins, so I did not need to take out the splitterā€¦ but that is not a huge deal either.

-Karen

27

Maybe it would be more useful if people donā€™t take out code, but use conditional compilation, eg

#if XojoVersion < kMinimumXojoVersionForStableAPI2 then

to make it as compatible as possible?

That would also allow to have ONE repository where everyone can contribute, instead of everyone doing their own thing.

28

At a minimum all Var declarations would need to be DIMs for that to be possible.

Donā€™t know yet if it does much string parsing but because of index changes API 2 could would need to be redone for API 1ā€¦ And once the New Controls wit the new event names come out the UI building would need to be largely separateā€¦

Not sure how realist your proposal isā€¦

-Karen

29

Why?

#if XojoVersion < kMinimumXojoVersionForStableAPI2 then
// ALL the old API 1 code goes here

#elseif
// the new API 2 code goes here

#endif

For example someone went to the trouble of rewriting Joeā€™s StringUtils module as API 2. What then? Maintain an API1 module and an API2 module? Fix bugs only in the API2 module? What if he needs an older version for a custom project?

ā€œLack of backwards compatibility is a lack of foresightā€ ā€¦ youā€™ll pay a price down the line. Just look at Xojoā€™s renaming events fiasco ā€¦ :man_facepalming:

30

Iā€™m assuming that it should run in 2019r1.1 and maybe earlierā€¦

There are 1098 Var declarations in ARGENā€¦ And DIM is not deprecatedā€¦

  • Karen
31

Thatā€™s why you would use a system wide variable - everyone can easily decide where he wants his cutoff to be, and even change his mind.

So? Still not an argument against my suggestion. Itā€™s simple, effective, and backwards compatible.

32

Well, they decided to go on with the fiasco, next chapter: two sets of controls one with normal events ones with new names events.

Messing up the mess even more.

1 Like
33

Ivan, the topic is backwards compatibility. Keep up!

:wink:

34

My point was keeping coding so it is both 100% Backward API 1 AND Forward API 2 compatible is a lot of work and far from trivial because of the differences - and API 2 will keep Divergingā€¦ Remember the new controls are comingā€¦

All that is a lot ask for an source project ā€¦ and there are not a lot of examples of Xojo open source projects that regularly updated over the long term that I am aware of.

As I mentioned earlier, Iā€™m finding making the open source version of ARGEN compatible with 2019r1.1 was not quite as straightforward as it seemed at firstā€¦

After I did the obvious changes the code runs and compiles fine in 2021r1.1 ā€¦ But while the same code compiles and starts up just fine in 2019r1.1, trying to actually use it one gets a NIL object exception that one does not get in 2021r1.1.

I have not been able to spend much time it yet, but so far I canā€™t find out whyā€¦

BTW from what I saw ARGEN still uses RecordSets ā€¦ which is API 1 so eventually that part would need to get redone for API 2.

The point is keeping it dual Xojo API would not be as trivial as you imply, I think.

-Karen

1 Like
35

That is YOUR topic only :rofl: :rofl: :rofl:

That is true, a lot of complains about what should be done, but not real code contributions.

Anyway, Why all the fuzz, this is a tool not intended to be run by end users.

Actually to run this tool Backwards compatibility DOESNT EVEN MATTER, if you dont have a license for the last xojo release, who cares, just install Xojo, run the tool in DEBUG MODE, generate the source, DONE :roll_eyes:

1 Like
36

I am thinking about making some modifications to ARGEN , if I can understand the code well enough.

For example I would like to fix/expand the Xojo datatypes supported by SQLite. Right now the types Xojo Database.FieldSchema returns are not always right according to the Sqlite affinity rulesā€¦ and it does not support all of Xojoā€™s data typesā€¦ And Sqlite field types can be any stringā€¦

One thing is I want to be able support more restricted types to let the compiler help keep things in the right range.

For example I could define an SQLite Data type to be UINT8ā€¦ If I use the SQLite pragma to get the field name and use that to figure out the XojoType I could have ARGEN define the Xojo Datatype to be Uint8

Also not all the DB type specific code is in the adaptor classesā€¦ If I could, I would like it all to be in those classes instead of spread out. That also would make changes like the one I mention above easier to manage/maintain.

  • Karen
1 Like
37

I wrote the imSplitter and it is meant to be completely open source, meaning: you can sell it, distribute it, extend it - just donā€˜t try to copyright it.

If you have issues with the current license, just let me know what would be more suitable for you. I can adapt it.

1 Like
38

Maybe is you change it for a MIT one?

39

ok, Iā€˜ll do that! Not tonight - now is time to chill out :grinning:

2 Likes
40

The entire Xojo language and framework is closed source. If you trust the plugin maker as you seem to, the decision about using a plugin in an open source Xojo project is merely about being skilful and having enough time to refactor and maintain that functionality. But is it really worth it?

41

Switched imSplitter license to MIT:

7 Likes