Re: Now that IUP is deemed viable, is it time to discuss the challenges?

new topic     » goto parent     » topic index » view thread      » older message » newer message

This thread should be about how to best provide a GUI for Euphoria users. For an up to date overview of what platforms run OpenEuphoria please consult the DownloadEuphoria page. Let's try not to let this thread get off-topic.

Let's make up some definitions for a moment to make the rest of this post easier to read.

  • Developer: A programmer hacking away at OpenEuphoria directly. This person directly contriubtes to OpenEuphoria either by modifying it's source code or maintaining OpenEuphoria packages/installers.
  • User: A programmer using OpenEuphoria to create software and solve problems.
  • Programmer: See User
  • Customer: This is the person a OpenEuphoria user writes a program for. The person may or may not be a programmer.

With these definitions in mind, and the fact that there are multiple dissimilar platforms let's approach the problem.

  1. For me, the single most important benefit of using OpenEuphoria is that I can target nearly 100% of all computer users as my Customer. I don't need to concern myself with what OS they prefer, or what processor they have. None of that matters to me as a user. The developers have already taken care of those challenges for me. At all costs, I would like to see this feature protected.
  2. The second most important benefit of using OpenEuphoria is the ability to translate OE code to C and compile it natively.


Honestly, if EU didn't have either of these 2 features when I first started evaluating it, I would have moved on immediately.

This problem we're facing with a built in GUI has been solved before. Below are some of the solutions and my opinion as to how they effect the features listed above.

  1. Statically link a GUI to OE.
  2. Statically link primitive features to OE. (Graphics, clipboard, mouse, etc)
  3. Provide DLL for a GUI
  4. Provide DLL for primitive features.
  5. Provide wrappers to existing GUI


Both options 1 and 2 seem to best protect feature 1. But, how would standalone executables work in that case?

Going the DLL route makes building executables more obvious, but now how do you keep the DLL and wrapper in lockstep? Where is the DLL on the user box? How does said DLL end up on the customer's/user's box? Where is the DLL on the customers box? How do users deploy software to multiple platforms?

Option 5 is what we're doing now with GTK and Wx. What can be done to make that less painful?

-xecronix

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu