1. Now that IUP is deemed viable, is it time to discuss the challenges?

The following questions cut from e-mail still go unanswered. These questions go beyond the GUI toolkit and lean more towards how a solution affects OpenEuphoria.

Looking at the 3 most successful projects with this same goal, how did they solve the problem? Java, Mono, Lazarus?

BTW, Mono actually publicly discussed what they tried and how they landed on their decision. http://www.mono-project.com/docs/gui/winforms/

e-mail said...

We really should start discussing how we are going implement a cross platform solution. Here are 4 ideas. If you have others, lets get them on the table so we can collectively evaluate them. As we evaluate possibilities, we should keep in mind ARM, OSX, and Windows.

How to make sure that the official toolkit and IDE will work on each platform it's is installed on? Options include:

  1. Statically link: works great for interpreter but not so good for compiler. Though this is probably the easiest to distribute across platforms.
  2. Binary distribute. Still not so bad but then the question of where to put the libs come into play. /usr/lib? /usr/local/lib? /usr/lib64? /.local/lib? IDK on OS X? System32 on Windows? Does this mean we need to create/maintain several different installers?
  3. Binary distribute option 2 - Go against the grain and install libs/dlls relative to eui. Then open_dll could also be to modified to look for dlls in a location relative to eui. (I like this option a lot)
  4. Source. OK, but what about pre-requisites? Like `make` for example. Probably a huge problem for Windows.


Also, another question that comes up is do we have a primary concern between interpreted and compiled user programs? Or are both concerns equal? If I had to choose, interpreted would be my primary concern.

-Xecronix

new topic     » topic index » view message » categorize

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

I think if we install Euphoria under /opt/euphoria-4.x on *NIX platforms, that will give us a consistent base onto which we can add more packages. So for things like IUP, we put the binaries in bin and the include files in include/iup. Everything should "just work" from there. A better solution to this would be to have an official package manager, but that is beyond the scope of the current discussion.

xecronix said...

Also, another question that comes up is do we have a primary concern between interpreted and compiled user programs? Or are both concerns equal? If I had to choose, interpreted would be my primary concern.

I don't think this is a concern if we are providing dynamic libraries. At the very least, we may need to improve EuDist so that it picks up the new libraries.

-Greg

new topic     » goto parent     » topic index » view message » categorize

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

xecronix said...
e-mail said...

We really should start discussing how we are going implement a cross platform solution. Here are 4 ideas. If you have others, lets get them on the table so we can collectively evaluate them. As we evaluate possibilities, we should keep in mind ARM, OSX, and Windows.

Hallo,

Just for my information. Windows is in a row with ARM and OSX?
So it is not a first class citizen anymore?
That means OE goes Linux and BSD in the future?
Or I'am wrong?

Andreas

new topic     » goto parent     » topic index » view message » categorize

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

andi49 said...

Hallo,

Just for my information. Windows is in a row with ARM and OSX?
So it is not a first class citizen anymore?
That means OE goes Linux and BSD in the future?
Or I'am wrong?

Andreas

Euphoria is multi-platform. (When Microsoft goes of business we will adapt to the next great operating system.)

The current problem is to find a beginner friendly GUI toolkit that can be packaged with Euphoria. A single multi-platform toolkit makes packaging and maintenance easier. The IUP wrapper, by Greg Haberek, is only a few weeks old and is getting the most attention right now.

I am still open to a three GUI option:

  • IUP as the multi-platform
  • possibly tinEWG on Windows
  • euGTK on Unix

Because IUP is universal it would get the most "official" attention. Users that only care about one platform would be directed to a suitable native toolkit.

When REDY goes multi-platform I will be an enthusiastic supporter.

All ideas and opinions are welcome

_tom

new topic     » goto parent     » topic index » view message » categorize

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

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 message » categorize

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

Just to add to the discussion:
1 - IUP dont have a native look and feel in OSX, it uses gtk emulation.
2 - While distributing dynamic linked apps in Windows or OSX is a matter of dropping dlls in app's folder, the situation is harder in Linux. Static linking could be the solution but it seems to be a complex topic in linux (google it). The dll (or .SO if you prefer) hell (the inaptitude of just distribute my software without the need to build a .deb or .rpm package) was the cause for me to leave linux development in the past.

new topic     » goto parent     » topic index » view message » categorize

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

elias_maluko said...

While distributing dynamic linked apps in Windows or OSX is a matter of dropping dlls in app's folder, the situation is harder in Linux. Static linking could be the solution but it seems to be a complex topic in linux (google it). The dll (or .SO if you prefer) hell (the inaptitude of just distribute my software without the need to build a .deb or .rpm package) was the cause for me to leave linux development in the past.

But this is actually not all that hard. Both VMware and Mozilla Firefox are able to do it (distributing their applications with dynamic libraries).

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu