Re: UI Committee Round 2
- Posted by xecronix Dec 14, 2015
- 3861 views
I'm trying something different.
- Developer: Someone directly responsible for hacking or packing OE.
- User: Someone who uses OE with the intention of writing a program.
- Customer: (aka OE User's Customer) The person that consumes a program written by a OE User.
DLL Option:
Concern: Where are the DLLs on the OE Users box?
Potential Solution: DLLs are located in a directory relative to $EUBIN
Discussion Point: Developers would be responsible for packaging DLLs for each supported platform.
Concern: How did the DLLs on OE User's box get there?
Potential Solution: Included with OE
Discussion Point: Developers would be responsible for packaging DLLs for each supported platform.
Concern: Where are the DLLs on the OE User Customer's box?
Potential Solution: In a location as determined by the OS and/or OS Distribution
Discussion Point: This makes it difficult to keep the DLL and wrapper in sync. The customer would be free to upgrade DLLs without even realizing the affect it could have on an installed program. This is especially true if the program is compiled. Who's area of concern is this? Developer, User, or Customer?
Potential Solution: In a location relative to the program executable. (This is currently our best solution IMO)
Discussion Point: This can be accomplished using eu.cfg as is demonstrated the Euphoria Editor written using IUP. However the customer is in no way obligated to run the program from the executable's directory. (thus affecting the path) The solution can then be enhanced by the use of a launcher program or script but this could feel a bit odd to a customer. (again as is demonstrated the Euphoria Editor written using IUP) This solution puts sits squarely in the User's domain. Does it belong there? Is there any help that could be offered at the developer level to help standardize/streamline this process?
Concern: How did the DLLs get on the OE User Customer's box?
Potential Solution: The OE User includes the DLL with his program.
Discussion Point: This puts the burden of deploying the needed DLL and potentially supporting DLLs with the user. Some might argue that this is fine but is it? One advantage of using OE is cross platform programming. I might not even have a Mac, for example, but I would expect my OE program to run on one. How would I know what needs to be included with my program for a Mac if I don't have a Mac? How would I get the DLLs? Would developers need to package the DLLs for every platform with each OE installer just so that I could build cross platform packages? (Potentially uncompiled programs because I may not be able to cross compile). Much of this might be addressable with documentation/tutorials on the subject. I'm not sure. (Hence the plea for discussions) BTW, in the above we could easily replace Mac with Windows or ARM. It is not as uncommon as some people may think that a person does not have access to a Windows box. I don't have access to one at work or at home for example. And some of you reading this may not have access to an ARM box.
Potential Solution: Dynamic installation of DLLs
Discussion Point: This requires the customer to have internet connection at least for the first run of the program. There are also other concerns related to managing a distributed deploy system.
Further Discussions:
The domain of the DLL problems becomes much simpler when limited to interpreted programs only. If limited this way, then DLLs could be located in a place relative to $EUBIN and the open_dll function modified to look there for DLLs.
BTW, these question have not been discussed yet either:
Is it a goal of this project to be able to create a "write once run anywhere" solution like Java and Mono for example?
Is it a goal of this project to be able to create a "write once compile anywhere" solution like Free Pascal?
Static Linking Option:
Some discussion on this has happened. I can easily see the benefit for interpreted programs but it's unclear to me how this would be beneficial for compiled programs. Does anyone have any input on this? Especially as it relates to cross compiled programs?
Runtime:
Could creating a "Runtime" DLL (or static lib) be a decent solution for cross compiled programs? Does anyone have any input on this potential solution? Essentially a single DLL (or static lib) that provides UI features. In this case it would mean building a single monolithic IUP DLL (or static lib). (Warning: this could easily evolve to include other "stuff" cross-platform... like ssl for example. Of course, that is beyond the scope of these discussions.)
