OpenEuphoria

1. Unified libraries to allow porting code to other oses

• Posted by jmduro May 23, 2015
• 2947 views

Porting source code to other OSes can be very painfull. With one library, a unique call to a function with multiple parameters does the job, and on another you have to call multiple atomic functions to get the same result.

GUIs like wxWidgets have several function names to change a value according to classes where win32lib uses the same function name. Porting can be a hunter game where you need to spend weeks reading the documentation for each GUI you are testing.

I think OpenEuphoria can leverage some differences, not all of course, so I began writing a set of unified libraries that share common specifications: same function names, same parameters if possible or close parameters if not, limited set of functions. Thank's to Irv for giving me the key to be able to do this.

The aim is to ease the step of porting Euphoria code from windows to multiplatform to linux and reverse. It is based on the following principle:

           \ OS        Windows        Multiplatform       Linux  
Skill level \       
             \  
  
Beginner               winSimple  <-->  wxSimple    <-->  linSimple  
                          ^                ^                 ^  
                          |                |                 |  
                          v                v                 v  
Advanced user          win32lib        wxEuphoria          euGtk  
                        arwen                              euQt  
                        tinEwg  
                        ...  

winSimple would be as simple as:

ifdef WIN32LIB then  
  include winlibSimple.e  
elsifdef ARWEN then  
  include arwenSimple.e  
elsifdef TIN_EWG then  
  include tinEwgSimple.e  
end ifdef  

So everyone who wants to port his code to another OS can do it at his skill level. As an example, if I know only win32lib, I will be able to port my program to use winlibSimple instead of win32lib. Then, porting most of the code to use wxSimple should be obvious because most of the job is done only by changing one line "include winSimple.e" by "include wxSimple.e" and defining a variable named WX_WIDGETS instead of WIN32LIB.

There should be few lines than could not be ported from win32lib to winlibSimple, so not ported to wxSimple, because they are Windows specific. For those, you will get help on the forum. With only a very basic knowledge of Linux you could run your first Linux program. Then at your speed, you could learn wxEuphoria to do more while being compatible with Windows or swap to pure Linux by using linSimple, and later EuGTK or EUQT if you want.

The first library I build is wxSimple. Here is the first version to show it's not just a dream:

include std/search.e 
public include wxeud.e 
 
public enum  --     wxGridSelectionModes 
  wxGridSelectCells, 
  wxGridSelectRows, 
  wxGridSelectColumns, 
  wxGridSelectRowsOrColumns, 
$ 
 
export object registry = {} 
 
public function wxCreate( integer class, object params ) 
  atom id = create( class, params ) 
  registry = append(registry, {id, class}) 
  return id 
end function 
 
public function getClass(integer id) 
  return vlookup(id, registry, 1, 2, -1) 
end function 
 
public procedure setText(object id, sequence text) 
  integer wxId, param 
  if sequence(id) then 
    wxId = id[1] 
    param = id[2] 
  else 
    wxId = id 
  end if 
  atom wxClass = getClass(wxId) 
  if find(wxClass, {wxListCtrl, wxListBox, wxChoice}) then 
    set_string( wxId, param-1, text ) 
  elsif find(wxClass, {wxFrame, wxButton, wxStaticText, wxComboBox, wxRadioBox}) then 
    set_label ( wxId,  text ) 
  elsif (wxClass = wxStatusBar) then 
    if sequence(id) then 
      set_status_text( wxId, text, param-1) 
    else 
      set_status_text( wxId, text, 0 ) 
    end if 
  elsif (wxClass = wxTextCtrl) then 
    set_text( wxId, text ) 
  end if 
end procedure 

Create your widgets with wxCreate instead of create, and you will be able to use the same function to set widgets text instead of many. These lines:

  set_label(frame, "Clicked") 
  set_label(button, "Clicked") 
  set_label(lbl, "Clicked") 
  set_label(radiobox, "Clicked") 
  set_label(combo, "Clicked") 
 
  set_status_text(sb, "Clicked", 0) 
 
  set_text(sle, "Clicked") 
 
  set_string(list, 0, "Clicked") 
 
  set_string(choice, 0, "Clicked") 
  set_choice(choice, "Clicked") 
 
  set_cell_value(grid, "Clicked", 0, 1) 

can be replaced by those lines:

  setText(frame, "Clicked") 
  setText(button, "Clicked") 
  setText(lbl, "Clicked") 
  setText(radiobox, "Clicked") 
  setText(combo, "Clicked") 
 
  setText({sb,1}, "Clicked") 
 
  setText(sle, "Clicked") 
 
  setText({list,1}, "Clicked") 
  setText({choice,1}, "Clicked") 
  set_choice(choice, "Clicked") 
 
  set_cell_value(grid, "Clicked", 0, 1) 

You still have access to wxEuphoria standard functions. Simple functions are designed for people who migrate from one OS to another, from one GUI to another, with few knowledge of the intended target. Advanced users can use standard functions.

Regards

Jean-Marc

3. Re: Unified libraries to allow porting code to other oses

• Posted by ryanj May 23, 2015
• 2864 views

This is one of the goals of Redy: to make a non-platform-specific GUI api. As a purist, i like to have as little non-euphoria code as possible, so my approach was different than the others: i use only foundational window and graphics functions so that there is much less api to wrap on each platform. The hard thing about that approach is i had to create my own widget toolkit from scratch. It took a few years of failures and learning how to be a better programmer before i finally found a design that works well. But, i believe it was worth the effort. There are still many missing features, but Redy works very well so far. What i am missing is a wrapper for x-windows or xcb for Linux to be able to create and manage windows and draw graphics on them. Once I have that, it won't be difficult to make Redy cross-platform.

5. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 23, 2015
• 2867 views

  set_label(frame, "Clicked") 
  set_label(button, "Clicked") 
  set_label(lbl, "Clicked") 
  set_label(radiobox, "Clicked") 
  set_label(combo, "Clicked") 
 
  set_status_text(sb, "Clicked", 0) 
 
  set_text(sle, "Clicked") 
 
  set_string(list, 0, "Clicked") 
 
  set_string(choice, 0, "Clicked") 
  set_choice(choice, "Clicked") 
 
  set_cell_value(grid, "Clicked", 0, 1) 

  setText(frame, "Clicked") 
  setText(button, "Clicked") 
  setText(lbl, "Clicked") 
  setText(radiobox, "Clicked") 
  setText(combo, "Clicked") 
 
  setText({sb,1}, "Clicked") 
 
  setText(sle, "Clicked") 
 
  setText({list,1}, "Clicked") 
  setText({choice,1}, "Clicked") 
  set_choice(choice, "Clicked") 
 
  set_cell_value(grid, "Clicked", 0, 1) 

I'm not trying to be critical here, just constructive, so please don't take this the wrong way. From the two code snippets you show above, it appears that in order to port a program from one platform/gui to another, you're going to have to search and replace a LOT of code.

I believe that if you used an object-oriented approach, e.g.:

set(frame,"text","Clicked") 
set(button,"text","Clicked").... etc. 

then switching to another platform or gui would require no change in program code, except to include the desired wrapper. It would then be up to the author of the specific wrapper to implement the appropriate call, or provide an error message to tell the programmer that the particular call is impossible.

That would also allow the wrapper author to provide a work-around. For example, in GTK, buttons don't have a "text" attribute. They do, however, have a "label". It would be a simple matter to add that "alias" to the wrapper(s), so the same code

set(button,"text"...)

would run on wxWindows and GTK, or whatever.

The concept of the needed basic controls are the same for all platforms (window, label, button, image, list...) Those are already - or could be - implemented in all of the GUI packages, afaik.

7. Re: Unified libraries to allow porting code to other oses

• Posted by ne1uno May 23, 2015
• 2864 views

python had anygui in the late 90's similar idea, lowest common denominator of all the gui toolkits. the project was mostly working but abandoned before it could get enough community support, devs moved on. I haven't used python much in the last 10 years so I don't remember any of the details.

with you 100% on consolidating functions. Qt has a variety of set & get functions for text. I was able to use the meta class functions on the widget pointer to find which class it belongs to and use a switch in the wrapper to call the right routine for a label or a text widget and a few other.

there are pro's and con's when diverging from the routine names of the widget sets. you can't always account for all the extra parameters. some widgets didn't derive from objects so they need their own routine names wrapped. now the user has no easy way to know which widgets setText will not work with.

9. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 23, 2015
• 2853 views

It seems to me that Redy would be the logical base for a cross-platform Euphoria wrapper. The syntax is clear and "euphoric", without a bunch of unnecessary cruft. It runs in Windows, and I think I could adapt EuGTK to run Redy source code unchanged, using GTK3. The GtkEngine and GtkPrinter files would add less than 80k to the Redy download, if someone was interested in running on Linux or OS X.

I know Ryan's idea is to make this a 100% Euphoria-coded package, but I'm not convinced that is practical in the long run. GTK offers a lot of things that would be very difficult to emulate in Eu code and x-windows. Likewise, Windows - especially Windows 7, 8 and 10 (what happened to 9, anyway?) have, or will have, a bunch of nifty new features also hard to emulate.

Redy would always be playing catch-up.

Take for example touch-screen capabilities: GTK has those already implemented, EuGTK has the code there to run them, and the next major Linux releases such a Ubuntu will be ready to use them. Who would even know where to start looking for a way to implement those on the bare metal?

11. Re: Unified libraries to allow porting code to other oses

• Posted by jmduro May 24, 2015
• 2770 views

set(frame,"text","Clicked") 
set(button,"text","Clicked").... etc. 

set(button,"text"...)

I'm not sure I got the concept, but as I already built some kind of object-oriented library in Euphoria, I wilt try to go this way.

For the time being, I don't see what it will change but this could be more visible once tested.

Regards

Jean-Marc

13. Re: Unified libraries to allow porting code to other oses

• Posted by jmduro May 24, 2015
• 2849 views

I think I understand. Something like set(object id, sequence property, object value). I don't understand how your "pretty simple" line works.

With my classes library, I would have to define a lot of classes, one per widget, defines all its methods and properties and create functions that instantiate that object like I did in my Database Visual Control Library. That is to say one source file per widget.

Here is an example of the way I create my own objects:

include constants.e 
include myLibs\myDebug.e 
include myLibs\myFile.e 
include myLibs\classes.e 
 
global constant 
  dbmemo_MLE = 1, dbmemo_RICHEDIT = 2 
 
------------------------------------------------------------------------------ 
 
procedure onChange(integer self, integer event, sequence params) 
  integer dbmemo, table 
 
  dbmemo = findComponentEntity(self) 
  if dbmemo > 0 then 
    table = getEntityProperty(dbmemo, dbmemo_TABLE) 
    void = callEntityMethod(dbmemo, table, tableUpdate, getText(self)) 
  end if 
end procedure 
 
------------------------------------------------------------------------------ 
 
-- params = {id,text,type,table} 
global function dbmemoCreate(integer parent, integer x, integer y, integer w, 
                             integer h, integer memoType, 
                             integer table, sequence field) 
  integer dbmemo, id 
 
  dbmemo = createEntity(TDBMemo) 
 
  if memoType = dbmemo_MLE then 
    id = createEx( MleText, "", parent, x, y, w, h, w32or_all({ES_AUTOVSCROLL,WS_VSCROLL}), 0 ) 
  elsif memoType = dbmemo_RICHEDIT then 
    id = createEx( RichEdit, "", parent, x, y, w, h, w32or_all({ES_NOHIDESEL,ES_AUTOHSCROLL,WS_HSCROLL}), 0 ) 
  end if 
  setEntityProperty(dbmemo, dbmemo_ID, id) 
  setEntityProperty(dbmemo, dbmemo_TYPE, memoType) 
  setEntityProperty(dbmemo, dbmemo_TEXT, "") 
  setEntityProperty(dbmemo, dbmemo_TABLE, table) 
  setEntityProperty(dbmemo, dbmemo_FIELD, field) 
 
  void = callEntityMethod(dbmemo, table, tableSetLink, {}) 
  setHandler(id, w32HChange, routine_id("onChange")) 
  return dbmemo 
end function 
 
------------------------------------------------------------------------------ 
 
-- empty control text 
-- params = {} 
function dbmemoClean(integer sender, integer dbmemo, object params) 
  integer id 
 
  id = getEntityProperty(dbmemo, dbmemo_ID) 
  setText(id, "") 
  return 0 
end function 
 
------------------------------------------------------------------------------ 
 
-- update control text according to its type 
-- yet, I don't see any need to differentiate MLE and RichEdit 
-- params = {content} 
function Update(integer sender, integer dbmemo, object params) 
  integer id 
 
  id = getEntityProperty(dbmemo, dbmemo_ID) 
  void = enableHandler(id, w32HChange, routine_id("onChange"), 0) 
  setText(id, params) 
  setEntityProperty(dbmemo, dbmemo_TEXT, params) 
  void = enableHandler(id, w32HChange, routine_id("onChange"), 1) 
  return 0 
end function 
 
------------------------------------------------------------------------------ 
 
-- show control 
-- params = {} 
function Show(integer sender, integer dbmemo, object params) 
  integer id 
 
  id = getEntityProperty(dbmemo, dbmemo_ID) 
  setVisible(id, w32True) 
  return 0 
end function 
 
------------------------------------------------------------------------------ 
 
-- hide control 
-- params = {} 
function Hide(integer sender, integer dbmemo, object params) 
  integer id 
 
  id = getEntityProperty(dbmemo, dbmemo_ID) 
  setVisible(id, w32False) 
  return 0 
end function 
 
------------------------------------------------------------------------------ 
 
  TDBMemo = defineClass("TDBMemo") 
 
  dbmemo_ID    = defineClassProperty(TDBMemo, "id", 0) 
  dbmemo_TEXT  = defineClassProperty(TDBMemo, "text", "") 
  dbmemo_TYPE  = defineClassProperty(TDBMemo, "type", "") 
  dbmemo_TABLE = defineClassProperty(TDBMemo, "table", 0) 
  dbmemo_FIELD = defineClassProperty(TDBMemo, "field", "") 
 
  dbmemoUpdate = defineClassMethod(TDBMemo, "Update", routine_id("Update")) 
  dbmemoShow   = defineClassMethod(TDBMemo, "Show",   routine_id("Show")) 
  dbmemoHide   = defineClassMethod(TDBMemo, "Hide",   routine_id("Hide")) 

And the way it is called:

  textField = dbtextCreate( 
      Win,  -- parent 
      100,  -- x position 
       62,  -- y position 
      148,  -- width 
       20,  -- height 
      ALIGN_LEFT, -- align 
      table,   -- table 
      "field2" -- field 
    ) 

The way to call a method is as follows:

  void = callEntityMethod(0, table, tableGoFirst, {}) 

Regards

Jean-Marc

15. Re: Unified libraries to allow porting code to other oses

• Posted by Bazzadude May 24, 2015
• 2763 views

I think this is a valid concern and (if we look at similar efforts in other languages) the Swing toolkit from Java is a great example of this problem.

Its pluggable look-and-feel capabilities were and are great - yet they still fall short of delivering a truly native experience to the point that Swing apps often offer a somewhat jarring UI.

17. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 24, 2015
• 2794 views

That's where computers come in handy - let it do the dirty work :)

The line is a 'prototype'. It defines the property and the parameters and parameter types needed to make the call.

When the first instance of an object (say a label) is created, that line is processed as follows:
1. the name "set_text" is converted to "gtk_label_set_text" - easy, since you already know you are dealing with gtk and a label.
2. "gtk_label_set_text" is looked up in the .dll or .so using define_c_proc() and the routine_id returned is appended to the line:
Now it looks like this:

{ 
  "set_text", 
  {50331649,150994948}, -- these are the P and S (just unique numbers, don't be concerned about them here) 
  0,   -- zero means no return value is expected 
  531, -- this is the routine to call, I refer to it as a 'vector' since it can be a call into a dll, or a call to a eu function. 
  0 -- this is used for other purposes, not important here. 
} 
 

To be exact, all the calls relating to a label are initialized in this way. Once, no matter how many labels you create, and only if your program is using labels. Otherwise, the entire GtkLabel structure remains untouched.

The P parameter just indicates that this particular call wants a pointer as the first parameter, and the S means it's expecting a string for the second. These are used in define_c_func(). They are also used later when you call set(somelabel,"text","FooBar") to assure that somelabel is a pointer to a label class, and that "FooBar" is a string. Since you can't pass strings directly to c functions, it also tells the set() call to convert that string into a pointer (via allocate_string).

A call which returns a result has a slightly different format:

   {"get_text",{P},S} -- wants a pointer to the label, and returns a pointer to a c string 

Since this has a return type indicated, the call was looked up using define_c_func(). Again, all these calls are 'initialized' the first time a label is declared. The S format of the return value tells get() to convert the string pointer from c back into a Eu string.

This may sound complex, but there are real benefits. One, you only need to lookup and 'register' functions for classes that are actually used in the current program. That saves a lot of startup time. Second, the prototype is dead simple to understand and convert from the documentation of the c call.

void 
gtk_label_set_markup (GtkLabel *label, 
                      const gchar *str); 

And it's never more than one line. Anybody can add features without knowing much at all about the underlying code. Say labels add a 'markup' property - like 'text', but using html. All that's needed is to add the line:

   {"set_markup",{P,S}} 

And you're done!

19. Re: Unified libraries to allow porting code to other oses

• Posted by jmduro May 24, 2015
• 2748 views

Well, I will let a good night pass before I try to understand the way you've done it. It's too much for my old brain at evening

Thank you very much for your explanations. to morrow, I hope I will get the light.

Good evening

Jean-Marc

21. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 25, 2015
• 2695 views

There are a few instances in GTK where something like that is done - where you wish to set a property of a 'child' of an object, when that child itself is generated internally as the result of creating the parent.

To do that, its necessary to call a Eu function which obtains the child and does the setting.

Using your example, and assuming the statusbar doesn't also have its own text which is settable:

{"text",{P,S},0,-routine_id("setStatusBarPanelText")} -- the prototype 
 
function setStatusBarPanelText(atom stbar, object txt) 
object panel = get(stbar,"child") 
set(panel,"text",txt) 
.... 

Note that the routine_id for the function above has been negated. This makes it easy to differentiate positive numbers which are pointers to calls in the .dll, from negative numbers, which are calls to Euphoria routines, so you use c_func or call_func as appropriate.

Of course, there might be a situation where the statusbar has text, and its panel also has text, I suppose. In that case, just use a different name for one, such as statusbar caption. Or even something like:

   {"panel.text",{P,S},-routine_id("setSbPanelTxt")} 

Using that, your program could call:

set(panelbar,"panel.text","FooBar")

"panel->text" would work, or whatever you like, these are just strings.
set(panelbar,"panel->text->color","blue") if you want to look like some other programming language :)

 {"cell_data",{P,I,I,S}} -- prototype for setting grid row, col, data 
 
Program code: 
  set(grid,"cell_data",2,4,"Something or other")  
 

23. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 25, 2015
• 2677 views

I'm thinking that would be a pretty big file.

25. Re: Unified libraries to allow porting code to other oses

• Posted by jmduro May 27, 2015
• 2584 views

Hi Irv,

It is based on wxEuphoria 0.1.7 which wraps the old wxWidgets 2.8.

Yes, wxEuphoria is a wrapper on a specific DLL.

Il is available, but wraps a DLL written in C, which itself refers to wxWidgets, as far as I understand. Honestly, I use it because it is multi-platform, but for a pure Linux system, or if the Windows version was distributed with a set of DLLs, I would not spend too much time on it as it is unmainained since many years and there is a lack of coherence in function naming in wxWidgets, and wxEuphoria follows wxWidgets as close as possible.

Better would be to have an version of EuGtK that shares syntax with a windows library: an eugtkSimple or whatever name it could get, in the KISS phylosophy (Keep It Simple ...). *Simple may not be the best way to name a set of libraries sharing a common syntax. a kis prefix might be more relevant, or something like that.

Regards

Jean-Marc

27. Re: Unified libraries to allow porting code to other oses

• Posted by _tom (admin) May 27, 2015
• 2615 views

Here is my thinking about graphical applications.

UI (User Interface) selection guide.

(1) Graphical Software: native, adopted, independent.

Native is "what comes with the operating system."

• For windows: what Microsoft gives you.
• For unix: GTK, QT, Enlightenment.

Advantages: nothing extra has to be installed, native look and feel.

Adopted is "what you add to make native graphics workable."

• For windows it could be wxWidgets, IUP, maybe GTK
• For unix it could be wxWidgets, IUP.
• Unix also allows a GTK system to have QT and others.

Advantages: UI becomes easier to program, can be multiplatform.
Disadvantage: extra software to install.

Independent is "your own graphical software."

• For windows: Java, Redy.
• For unix: Java, (? Redy).

Advantages: can be easy to program, can be multiplatform.
Disadvantages: extra software to install, unique look and feel.

(2) Toolkit: programmer interface to graphical software.

Bare metal or program graphics directly.

Painful...don't do it.

Toolkit is paired with graphical software.

Choice of graphics & toolkit becomes a matter of personal choice.

(3) IDE: UI layout program.

windows

• native: almost mandatory to have IDE

unix

• can program euGTK without IDE, can use Glade if desired

(4) Final considerations: size, complexity, personal choice.

Conclusion

You will never get one "true" UI for any system since there are too many subjective choices.

Tom's Experiment

Rename EWG|tinEWG to eWui (Euphoria Widget User Interface). This allows for eTui (Euphoria Text User Interface) which could be a clean-up of existing I|O routines and documentation.

Here is my windows experiment for creating a UI application.

Pick tinEWG as the toolkit: native graphics (no extra installation), toolkit, IDE, small and managable for a beginner.

The idea is to have a database format for the IDE that can be edited directly and uses a universal syntax (see Jean-Marc unified libraries, see Ryan Redy )

First example from EWG would look like this:

sequence ui = 
{   { "window", "WinHwnd" }, 
    { "title", "eWui -- the First program" }, 
    { "icon", "T.ICO" }, 
    -- children to window follow  
    {  
      { 
        { "Button", "button1" }, 
        { "title", "Info" }, 
        { "click", ` 

                   InfoMsg("Programmed in Euphoria with eWui Toolkit","eWui") 
                   ` }, 

        {} -- button has no children 
      } 
    }   
}  

Second example from EWG would look like this:

sequence ui = 
{"""Window = "WinHwnd", 

    Title = "eWui -- Two Buttons", 
    Icon = "EuWinGui.ICO", 
    WindowType = NoSysWin, 
    -- example has two children 
 """, { 

        {"""Button = button1, 

            Title = Close, 
            Position = `10, 10` 
            Click = `if AskMsg("Are you sure you want to quit?","eWui") then 

                        exit 
                     end if 
                    `, 

         """, {} 

         }, 
         {"""Button = button2, 

            Title = About, 
            Position = `145, 10`, 
            Click = `InfoMsg("A simple window with two buttons.\nCreated with eWui","eWui -- about" )`             
           """, {} 

          } 
       } 
}   

Writing a program to convert from the database to a working EWG|tinEWG program was not difficult--it worked. It may be possible to use this information to output a GTK program. I have not yet tried to modify the existing IDE to output in this format.

_tom

29. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 27, 2015
• 2618 views

I agree, and I think you've summarized the situation much better than I could.

There's never going to be a consensus, and with so few people using Euphoria, if we took a vote, most likely each approach you mentioned would get about one vote.

I don't know what the minimum number would be to set up a stable working group, but I doubt we could do that for anything other than -perhaps- a re-designed win32lib.

31. Re: Unified libraries to allow porting code to other oses

• Posted by irv May 27, 2015
• 2538 views

Ha! I'll bet you're not as old as me - I've been retired since 2004.

A universal syntax is the first thing that is required if you're going to have a cross-platform language.

Normally, I detest object-oriented programming. Sometimes it is enforced to ludicrous extremes. However, for a GUI, an object-oriented approach is exactly what is needed, because it 'fits' what you're working with: interface objects.

Euphoria isn't object-oriented, of course, but that makes little difference, since we're obligated to write some kind of 'wrapper' to interface with whatever GUI we're using anyway. That wrapper can very easily implement a limited object-oriented syntax. EuGTK is basically an OOP language without a way to create "new" objects. It only has access to properties of objects that already exist in GTK.

33. Re: Unified libraries to allow porting code to other oses

• Posted by andi49 May 27, 2015
• 2545 views

Sorry to disturb...

But this, makes me remeber this thread http://openeuphoria.org/forum/118056.wc#118056

Andreas

35. Re: Unified libraries to allow porting code to other oses

• Posted by irv Jun 05, 2015
• 2450 views

I see approximately 160 unique 'objects' that wx uses: wxButton, wxRadioButton, wxToggleButton, for example.

Surely, a list with 160 items is going to be less trouble to maintain than a sequence of thousands of switch statements. Faster, too, since there's no need whatsoever to use an actual lookup or switch...case to access the object.

wxButton could be a simple number (enum) which serves as an index into an array. Once the correct set of properties for wxButton has been obtained from that array, it's easy to look thru that short list and find "set_text". No object will have ALL possible properties, so that list will be short enough to maintain easily.

Secondly, you won't need a function to set wxButton text and another to set wxToggleButton text. Just let wxToggleButton inherit the common properties from wxButton.

As for differing names, I suppose wxWidgets wasn't as carefully thought out as GTK, but even GTK has some name variations. Your prototypes will probably have to do the translation. For example:

          case wxStatusBar then set_status_text( id, Value, 0 )  

If you really want to be able to write:

 set(sb,"text","Foo") 

Then your prototype will need to look something like this:

  {"set_text","wx_statusbar_set_status_text",{P,S}} 

That would do the translation between the syntax you want to use and whatever might be the actual function name in wx dll.

But I ask once again - is wxWidgets (the current version) written in C? If C plus-plus, how do you plan to link to the functions?

There is no point in writing a wrapper for something that is no longer maintained.

37. Re: Unified libraries to allow porting code to other oses

• Posted by irv Jun 05, 2015
• 2402 views

Then you misunderstand. I have several Windows programs I wrote (years ago) using win32lib and Judith's IDE.

Similar programs using EuGTK tend to be about one-third as large, unless I also use Glade, in which case they can be even smaller.

39. Re: Unified libraries to allow porting code to other oses

• Posted by irv Jun 06, 2015
• 2350 views

constant panel = create(GtkBox, win, VERTICAL) 
 
constant lbl1 = create(GtkLabel, panel) 
    set(lbl1,"markup",docs) 
     
constant img1 = create(GtkImage, panel, icon) 
    
constant lbl2 = create(GtkLabel, panel, icon) 
 
main(win) 

The 'more Euphoria's style' example would be easy to match with EuGTK. But doing that would limit your options. For example, sometimes you want an object (label, image, or whatever) to take all the space available. Other times you might want it to only take as much space as it needs, or to share space equally (or not equally) with the other objects in the same container. To do that using the style you suggest would get tricky. That's why you have 3 possible calls - add, pack_start, and pack_end. The 2 pack calls have several options to control how the 'sharing' takes place.

Secondly, you don't always want to add controls to containers in the same order as you create them, or at the time you create them. To require that would force you to write more complex Eu code.

41. Re: Unified libraries to allow porting code to other oses

• Posted by BRyan Jun 06, 2015
• 2336 views

May be you guys are thinking backwards.

Suppose you design a IDE that you use to describe your program.

Then when you select the output of the IDE.

You select the code to generate to use the desired OS GTK WIN32 etc.

43. Re: Unified libraries to allow porting code to other oses

• Posted by jmduro Jun 06, 2015
• 2340 views

Personally, I prefer the way Lazarus does the job: the menu bar, the tool bar and the status bar grow with the size of the window. Panels have positioning properties to align on left, top, right or bottom sides, or on the remaining free area. I don't know what sizers are, even if the program uses them internally.

For components sitting on the panels, it is very simple: when the user resizes the window, there is an onResize event, caught by a function. In that function, I can resize which components I want to resize.

I will check if I can use an LFM file written by Lazarus to draw a windows with Win32lib. It may be possible.

Jean-Marc

45. Re: Unified libraries to allow porting code to other oses

• Posted by jmduro Jun 06, 2015
• 2367 views

Here we face the root of the problem: Euphoria is used by hobbyist like me and by professional programmers like you.

For hobbyists, it must remain simple to use. For professional programmers, it must fit all situations.

47. Re: Unified libraries to allow porting code to other oses

• Posted by jimcbrown (admin) Jun 07, 2015
• 2301 views

You say that, but then there's this:

It seems to me that the professional programmer would be the one able to work through these issues, going thorugh 7500 lines of code and tweaking the few hundred or so that need to be tweaked, while the hobbyist would be the one asking for automatic resizing/repositioning (so they can save the time and work on other, more fun stuff).

Having worked with GTK before, it's easy enough to do things in the fixed position format. While I agree with irv that sizers are easier and more hobbist friendly, not all UI libraries support it (notably, w32lib does not). I thought this is what wxSimple/eugtkSimple/et al was suppose to deal with, btw.

49. Re: Unified libraries to allow porting code to other oses

• Posted by euphoric (admin) Jun 08, 2015
• 2293 views

It's true that, out of the gate, Win32Lib does not support it, but, when I did use Win32Lib, I used Greg's xControls library (there are others) to handle that for me. I concur with Irv on this one: sizers are far more beneficial for UI development. They are both aesthetically and functionally more appealing.

There is no way I'd go back to static sizing/positioning. Are you kidding?!