1. Unified libraries to allow porting code to other oses

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

new topic     » topic index » view message » categorize

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

jmduro said...

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.

What does the latter have to do with the former? wxWidgets might use different names for different classes, but the same naming scheme would apply across all wxWidget supports platforms.

jmduro said...

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  
                          ^                ^                 ^  

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.

This was the original intent of the original author of win32lib, dcuny. In addition to http://webs.lanset.com/dcuny/win32.htm there was also a dos32lib http://webs.lanset.com/dcuny/dos32.htm and the idea was that one could switch between the two simply by changing "include win32lib.ew" to "include dos32lib.e" - and there was also a linux version, see http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=gtk+library and http://www.RapidEuphoria.com/gtklib.zip

Then the original author moved on to other things, win32lib was taken over by a group that no longer cared about cross platform compatibility, and lack of interest killed off the dos32lib and gtklib versions.

Maintaining a cross platform UI toolkit/library is hard work. Even something like winSimple (which imvho is very badly named, as it sounds windoze-centric) would be a lot of effort.

jmduro said...

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

Wouldn't this break the desired goal, cross compatibility? Any program that uses the standard wxEuphoria functions would not be able to change the library from wxSimple to winlibSimple.e without having someone manually addressing issue of the advanced calls.

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

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

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.

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

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

jimcbrown said...

What does the latter have to do with the former? wxWidgets might use different names for different classes, but the same naming scheme would apply across all wxWidget supports platforms.

I probably don't understand the question. The source code might be the best support for an answer. To set text I have a set of functions

  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 

To get text, I have another set of functions, but function names to get text are not always coherent with functions to set text:

  if find(wxClass, {wxListCtrl, wxListBox, wxChoice, wxComboBox}) then 
    text = get_string_selection( wxId ) 
  elsif find(wxClass, {wxFrame, wxButton, wxStaticText, wxRadioBox}) then 
    text = get_label ( wxId ) 
  elsif (wxClass = wxStatusBar) then 
    if sequence(id) then 
      text = get_status_text( wxId, param-1) 
    else 
      text = get_status_text( wxId, 0 ) 
    end if 
  elsif (wxClass = wxTextCtrl) then 
    if sequence(id) then 
      text = get_text_line( wxId, param-1 ) 
    else 
      text = get_text_value( wxId ) 
    end if 
  end if 

set_string but get_string_selection, set_text but get_text_line or get_text_value. I spend a lot of time to find the correct function names according to the classes, and sometimes the documentation is outdated and refers to non-existing names. With the wxSimple library, users avoid this problem.

jimcbrown said...

Even something like winSimple (which imvho is very badly named, as it sounds windoze-centric) would be a lot of effort.

It is badly named, that's right, but winSimple is windows-centric, it does not only sound windows-centric. It has just a syntax which is common to wxSimple or linSimple.

jimcbrown said...

Wouldn't this break the desired goal, cross compatibility? Any program that uses the standard wxEuphoria functions would not be able to change the library from wxSimple to winlibSimple.e without having someone manually addressing issue of the advanced calls.

wxSimple will never be exhaustive and do it all. I don't think I can achieve a unique cross-platform library. There will always be something specific to a platform or to a GUI. For example wxWidgets supports networking, win32lib does not. So the goal is not to get full cross compatibility: it is to let people do easily 80% of the porting job and let advanced users help them terminate with the remaining 20%.

Regards

Jean-Marc

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

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

jmduro said...

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

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.

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

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

jmduro said...

To get text, I have another set of functions, but function names to get text are not always coherent with functions to set text:

set_string but get_string_selection, set_text but get_text_line or get_text_value. I spend a lot of time to find the correct function names according to the classes, and sometimes the documentation is outdated and refers to non-existing names. With the wxSimple library, users avoid this problem.

I see, this is not a cross platform issue at all, but something completely different. Making the names of various functions simpler and more consistent so it is easier to learn for a user.

jmduro said...

wxSimple will never be exhaustive and do it all. I don't think I can achieve a unique cross-platform library. There will always be something specific to a platform or to a GUI. For example wxWidgets supports networking, win32lib does not. So the goal is not to get full cross compatibility: it is to let people do easily 80% of the porting job and let advanced users help them terminate with the remaining 20%.

Regards

Jean-Marc

Ok. This sounds quite reasonable.

ryanj said...

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.

A worthy goal imvho. David Cuny did something similiar with his mwin ("Minimalistic Windows") libraries some time back, and wxWidgets has a wxUniversal toolkit that is based on the same idea.

ryanj said...

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.

I can help with that: http://openeuphoria.org/eubins/misc/xlib.tbz

(Note that this code is not all mine - Pete E. and David Cuny and Elliot de S. all contributed to this. Back in 2001.)

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

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

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.

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

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

We need to be very cautious about using low-level functions - programming to the 'bare metal' you might say.

I can already see the posts about "I won't use -x- because the windows don't look like they should" - IOW, not native to the platform. That's already happened more than once.

In addition, how do you to account for user preferences, such as changes in fonts/sizes, window themes, etc? How about interacting with the taskbar?

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

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

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?

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

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

If there was a common library for Windows and Linux, it would be so nice that I would stop working on portability immediatly!

Do I dream or has it a chance to become reality in the following two years?

I can be patient if needed. smile

Jean-Marc

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

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

irv said...

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.

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

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

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

Let me try to explain what I mean:

if you begin with an action - set_text, for example, then the set_text function must examine the type of object to be set, and then call the correct function to do the setting. This could be done with a switch. Each action - set_text, get_text, set_color, etc. would have a (fairly long) list of switches.

Now, with any major set of GUI controls, there are going to be a huge number of possible actions - thousands - therefore, lots of code, and not all that easy to maintain. Whenever you need to add a new one - set_background, for example, you're going to have to write another long list of switches : case window then ... case button then ... etc. A case for each type of control that can change its background. Look at win32lib, for example. You will see a lot of "if ctrl_Type[ ID ] = ..." lines in each call. Lots of code, lots of opportunity for bugs.

On the other hand, there will be a smaller number of controls, and your call to set(control,"text",...) will already 'know' to look only at actions that are defined for that particular control. And you wouldn't need to use any switch statements to find the correct function, either. You can 'lookup' in that control's list of actions the one named "set_text" using fast built-in Eu functions like vlookup.

In most cases "set_text" would not be the name of the actual function call. It could be anything you choose that makes sense. For example, in EuGTK, "set_text" maps to "gtk_label_set_text" in libgtk3.so - for labels. It is also found as "gtk_entry_set_text" for GtkEntry widgets, and as "gtk_clipboard_set_text" for clipboards, where it needs an extra parameter. That causes no problem, since the looked-up info specifies the number and types of parameters the control is expecting. It could just as easily map to "SetWindowTextA" in user32.dll (or whatever) when using Windows, with a bit more work.

By doing things this way, each "set_text" takes exactly one line of code, for each control that actually can 'set text'. the line can be pretty simple, too:

widget[GtkLabel] = {"gtk_label",  
{GtkMisc,GtkWidget,GtkBuildable,GObject}, -- common properties inherited from lower-level controls 
    {"new",{S},P}, 
    {"set_text",{P,S}}, -- < this is all you'd need to add 
    {"get_text",{P},S}, 

For Windows, where the .dll routine names aren't so logically named, you'd probably have to make that line something like:

   {"set_text",{P,S},user32,"SetWindowTextA"} -- or something similar 
new topic     » goto parent     » topic index » view message » categorize

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

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

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

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

A more simple way to follow your recommendation would be:

public procedure set(object id, sequence property, object value) 
  integer wxId, param 
  if sequence(id) then 
    wxId = id[1] 
    param = id[2] 
  else 
    wxId = id 
  end if 
  atom wxClass = getClass(wxId) 
  switch wxClass of 
  case wxListCtrl then 
    if equal(property, "text") then 
      set_string( wxId, param-1, text ) 
    end if 
  case wxListBox then 
    if equal(property, "text") then 
      set_string( wxId, param-1, text ) 
    end if 
  case wxChoice then 
    if equal(property, "text") then 
      set_string( wxId, param-1, text ) 
    end if 
  case wxFrame then 
    if equal(property, "text") then 
      set_label ( wxId,  text ) 
    end if 
  case wxButton then 
    if equal(property, "text") then 
      set_label ( wxId,  text ) 
    end if 
  case wxStaticText then 
    if equal(property, "text") then 
      set_label ( wxId,  text ) 
    end if 
  case wxComboBox then 
    if equal(property, "text") then 
      set_label ( wxId,  text ) 
    end if 
  case wxRadioBox then 
    if equal(property, "text") then 
      set_label ( wxId,  text ) 
    end if 
  case wxStatusBar then 
    if equal(property, "text") then 
      if sequence(id) then 
        set_status_text( wxId, text, param-1) 
      else 
        set_status_text( wxId, text, 0 ) 
      end if 
    end if 
  case wxTextCtrl then 
    if equal(property, "text") then 
      set_text( wxId, text ) 
    end if 
  end if 
end procedure 

Jean-Marc

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

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

irv said...

I can already see the posts about "I won't use -x- because the windows don't look like they should" - IOW, not native to the platform. That's already happened more than once.

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.

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

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

This second way seems promising. I have just one hesitation about some object characteristics. Objects are sometimes identified as id, as {parent, id} (as a widget in another modal window) or as {id, section} (as a panel in the status bar).

Should this additional identification stay in the identification id (atom or sequence) or should it be extracted as a parameter?

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

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

jmduro said...

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.

Regards

Jean-Marc

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!

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

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

Wrapping wxWidgets using a similar idea wouldn't be too hard, the names may vary a bit. But wrapping Windows !?!

Here's get_text for a window or button, according to win32lib:

  elsif find(ctrl_Family[pId], {WINDOW, BUTTON, STATIC}) then 
        iLength = sendMessage( pId, WM_GETTEXTLENGTH, 0, 0 ) 
        if iLength > 0 then 
            iLength += 1 
            buffer = w32acquire_mem(0, iLength ) 
 
            iLength = sendMessage( pId, WM_GETTEXT, iLength, buffer ) 
            lCapText = peek( {buffer, iLength} ) 
            w32release_mem( buffer ) 
 
        end if 

Are you kidding me?

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

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

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 smile

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

Good evening

Jean-Marc

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

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

jmduro said...

This second way seems promising. I have just one hesitation about some object characteristics. Objects are sometimes identified as id, as {parent, id} (as a widget in another modal window) or as {id, section} (as a panel in the status bar).

Should this additional identification stay in the identification id (atom or sequence) or should it be extracted as a parameter?

I answer my own question:

  • id (atom) or {parent, id} (sequence) reference an object
  • {id, section} (sequence) doest not reference an object but some part of it (as a panel in a statusbar for example)

So in the syntax of setProperty(object id, sequence Property, object Value), section should not be part of id. But it is neither a property or a value, it remains an extra identification value. Any advice on how to include it in the syntax of the setProperty function?

May be this way: setProperty(object id, object section=0, sequence Property="", object Value=0)

This would permit to use setProperty even with a grid to put text in a cell:

  • setProperty(grid, {row, col}, "text", "Cell")
  • setProperty(statusbar, panel, "text", "Ready")
  • setProperty(button, 0, "text", "Ok")

I don't like this section parameter in second position. May be at the last position would be better.

Regards

Jean-Marc

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

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

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")  
 
new topic     » goto parent     » topic index » view message » categorize

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

I have uploaded the first draft of wxSimple on RDS site.

"Our" concept should be usable with any GUI. I must try it with EuGTK with the same test program (same appearance) and also with Win32Lib, tinEwg, and so on.

I wonder if it could be one unique over-the-top cross-GUI library or not, instead of being a set of libraries, one per GUI.

Regards

Jean-Marc

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

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

jmduro said...

I have uploaded the first draft of wxSimple on RDS site.

"Our" concept should be usable with any GUI. I must try it with EuGTK with the same test program (same appearance) and also with Win32Lib, tinEwg, and so on.

I wonder if it could be one unique over-the-top cross-GUI library or not, instead of being a set of libraries, one per GUI.

Regards

Jean-Marc

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

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

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

Before I get too deeply into this I would like to know:

Is this wxWidgets 3? or the old 2.8?

Will it require distribution of an .so or .dll other than those installed by wxWidgets itself?

Is this already available? Can it be written in Euphoria? Can we maintain it?

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

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

Hi Irv,

irv said...

Is this wxWidgets 3? or the old 2.8?

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

irv said...

Will it require distribution of an .so or .dll other than those installed by wxWidgets itself?

Yes, wxEuphoria is a wrapper on a specific DLL.

irv said...

Is this already available? Can it be written in Euphoria? Can we maintain it?

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

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

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

Is it true then that there is still no way to link library functions written in C?

I don't like the idea of having to depend on 3 layers of 'wrappers', some of which we would have no way to control.

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

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

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

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

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

irv said...

Is it true then that there is still no way to link library functions written in C?

I don't like the idea of having to depend on 3 layers of 'wrappers', some of which we would have no way to control.

I don't either but I'm pragmatic. Better this than nothing. It could be a first step towards something less dependent.

I would like to have a tbrowse (EuCom) for Linux. It would be easier than parsing the source code.

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

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

_tom said...

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.

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.

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

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

_tom said...

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 )

This seems to be close to Irv's way of programming with EuGtk. I'm getting old. I was never able to use Win32lib's createForm which uses the same principle or Glade.

    createForm({ 
        "Window, Arena, size=(0,0), at=(0,0), flags=(new,ws_caption,ws_sysmenu)" & 
           ", event=(paint,click)" 
    }) 

It seems simple, but I just can't process it.

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

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

jmduro said...
_tom said...

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 )

This seems to be close to Irv's way of programming with EuGtk. I'm getting old. I was never able to use Win32lib's createForm which uses the same principle or Glade.

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.

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

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

irv said...

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

Yes! I found the one who will help me port Euphoria on my TRS-80 Level 1 model III with a huge amount of 4 KB RAM. smile

The Trash 80 was my first computer but I'm still far from getting retired. I'm about to be 55.

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

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

_tom said...

[...]

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.

[...]

_tom

Sorry to disturb...

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

Andreas

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

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

irv said...

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")  
 

Hi Irv,

Here is the complete code to set the property text for all widgets supporting it:

constant HEADER = 1, FOOTER = 2 
 
-- set a property of a widget 
public procedure setProperty(object Id, sequence Property, object Value, object Section=0) 
  integer id, parent, param1, param2 
  if sequence(Id) then 
    parent = Id[1] 
    id     = Id[2] 
  else 
    id     = Id 
  end if 
  if sequence(Section) then 
    param1 = Section[1] 
    param2 = Section[2] 
  else 
    param1 = Section 
  end if 
  atom class = getClass(id) 
  if equal(Property, "text") then 
    if atom(Section) then 
      if Section = 0 then 
        switch class do 
          case wxRichTextCtrl, wxTextCtrl then set_text( id, Value ) 
          case wxButton, wxDefButton, wxToggleButton then set_button_label( id, Value ) 
          case wxFrame, wxRadioBox, wxStaticText then set_label( id, Value ) 
          case wxTextAttrEx then set_textattrex_bullet_text( id, Value ) 
          case wxStatusBar then set_status_text( id, Value, 0 ) 
        end switch 
      else 
        switch class do 
          case wxAuiNotebook then aui_notebook_set_page_text( id, Section, Value ) 
          case wxListCtrl then set_column_label( id, Section, Value ) 
          case wxChoicebook, wxListbook, wxNotebook, wxToolbook, wxTreebook then set_page_text( id, Section, Value ) 
          case wxStatusBar then set_status_text( id, Value, Section ) 
          case wxBitmapComboBox, wxChoice, wxComboBox, wxListBox, wxListCtrl then set_string( id, Section, Value ) 
          case wxTreeCtrl, wxTreeEvent then set_tree_item_text( id, Section, Value ) 
          case wxToolBar, wxToolBarItem then set_tool_label( id, Section, Value ) 
          case wxMenu, wxMenuBar, wxMenuItem then set_menu_label( id, Section, Value ) 
        end switch 
      end if 
    elsif (length(Section) = 2) and find(class, {wxGrid, wxGridCellAttr, wxGridCellAutoWrapStringEditor, wxGridCellEditor}) then 
      if Section[1] = 0 then 
        set_col_label( id, Section[2]-1, Value ) 
      elsif Section[2] = 0 then 
        set_row_label( id, Section[1]-1, Value ) 
      else 
        set_cell_value(id, Value, Section[1]-1, Section[2]-1) 
      end if 
    elsif (length(Section) = 3) and (class = wxRichTextPrinting) then 
      if Section[1] = HEADER then 
        set_richprint_footer_text( id, Value, Section[2], Section[3] ) 
      elsif Section[1] = FOOTER then 
        set_richprint_header_text( id, Value, Section[2], Section[3] ) 
      end if 
    end if 
  end if 
end procedure 

You can notice that original functions have various names, that parameters are not always in the same order and that parameters length differ. How could I build a list of prototypes your way in this conditions?

As all this code is only for one property, my feeling is that there is no benefit setting all the properties with one unique huge function. If you take a look at the function list I uploaded in ODS form, you will have an order of magnitude of the size it could reach. One function per property as previously coded would not be less maintainable than such a unique huge function.

Regards

Jean-Marc

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

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

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.

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

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

irv said...

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.

Sorry irv,

I thought I answered your question previously. wxWidgets is written in Cplusplus that's why Matt and Greg built a C wrapper before the Euphoria Wrapper. I know it's a bit too much wrappers:

wxSimple -> wxEuphoria -> libwxeu -> wxWidgets 
  eu            eu           C          C++ 

I would like to have one syntax scheme for both Windows and Linux, even if one is based on whatever windows library and the other on EuGTK. EuGTK is great but I find it a little difficult to learn and I find GTK on Windows too heavy.

This could be leveraged by a common syntax, but EuGtk seems more atomic than Win32lib or friends: it needs more lines of code as far as I can understand.

Regards

Jean-Marc

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

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

jmduro said...

This could be leveraged by a common syntax, but EuGtk seems more atomic than Win32lib or friends: it needs more lines of code as far as I can understand.

Regards

Jean-Marc

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.

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

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

irv said...

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.

You are surely right but EuGtk gives that impression. Let's take some of your code as an example (test135.ex):

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

I would have expected something more like that which seems to me close to Euphoria's style:

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) 

I guess this can't be done because it does not seem to be compatible with use of sizers (which usage I still don't understand).

Jean-Marc

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

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

jmduro said...

I would have expected something more like that which seems to me close to Euphoria's style:

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) 

I guess this can't be done because it does not seem to be compatible with use of sizers (which usage I still don't understand).

Jean-Marc

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.

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

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

irv said...

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.

Bouh hou, I cry! smile Everytime I want to do something with GTK, it is more complicated than expected. I hate sizers! When do we turn back to good old Basic?

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

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

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.

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

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

Like the example given by Tom in reply #27, or with UI files like Glade, or with form descriptors like Lazarus lfm files?

Why not? There are many models available, which one is the more convenient? There is also a gap between writing an UI description and getting the parser that will do the job.

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

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

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

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

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

jmduro said...

Bouh hou, I cry! smile Everytime I want to do something with GTK, it is more complicated than expected. I hate sizers! When do we turn back to good old Basic?

I suspect you've never had to change a few dozen or a few hundred lines of code because the customer decided he needed one more button or another label. I have one, written years ago with bare Eu and win32lib, that's still in use. Try browsing thru 7500 lines of code like the following, looking for an error in placement, and explain how that's easier!

,LText113 = create( LText, "Amount", CustomerWindow, 320, 248, 100, 24, 0 ) 
,LText89 = create( LText, "New Balance", CustomerWindow, 470, 316, 110, 24, 0 ) 
,CustCount = create( LText, "Count", CustomerWindow, 368, 8, 240, 24, 0 ) 
,CustFirstButton = create( PushButton, "<<First", CustomerWindow, 16, 344, 70, 30, 0 ) 
,CustPrevButton = create( PushButton, "&Prev", CustomerWindow, 88, 344, 70, 30, 0 ) 
,CustNextButton = create( PushButton, "&Next", CustomerWindow, 160, 344, 70, 30, 0 ) 
,CustLastButton = create( PushButton, "Last>>", CustomerWindow, 232, 344, 70, 30, 0 ) 
,CustMenuPrefs = create( Menu, "&Preferences", CustomerWindow, 0, 0, 0, 0, 0 ) 
,CustPrefsSortbyCode = create( MenuItem, "Sort by &Code", CustMenuPrefs, 0, 0, 0, 0, 0 ) 
,CustPrefsSortbyCompany = create( MenuItem, "Sort by Company &Name", CustMenuPrefs, 0, 0, 0, 0, 0 ) 
,CustPrefsSortbyZip = create( MenuItem, "Sort by &Zip Code", CustMenuPrefs, 0, 0, 0, 0, 0 ) 
,CustPrefsSortbyBillCycle = create(MenuItem, "Sort by Billing Cycle", CustMenuPrefs, 0, 0, 0, 0, 0) 
,CustScreenEdit = create( PushButton, "&Edit", CustomerWindow, 16, 312, 70, 30, 0 ) 
,LText112 = create( LText, "Last Payment", CustomerWindow, 320, 164, 120, 24, 0 ) 
,CustDelButton = create( PushButton, "Delete", CustomerWindow, 160, 272, 70, 30, 0 ) 
,CustomerSaveButton = create( PushButton, "&Save", CustomerWindow, 88, 312, 70, 30, 0  

That's just one problem with fixed positions and sizes. Another comes when your client decides he can't read the labels or list items easily, and insists on a larger font size. The third comes when he changes to a bigger monitor, and your program can't resize itself to fit the new screen. The fourth involves changing languages. So far, all my clients have been English speakers, but I do understand that sometimes Spanish captions can be longer than the English eqivalent, and no longer fit in the space you allotted.

Of course, a drag-and-drop IDE cures the problem of placing the items, but doesn't help with the rest.

As for Basic - what can I say? It's like going to the airport, asking to fly a plane, and claiming you are qualified because "I made lots of paper airplanes in elementary school". You're going to have a lot of trouble finding a copilot.

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

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

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.

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

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

jmduro said...

Personally, I prefer the way Lazarus does the job: the menu bar, the tool bar and the status bar grow with the 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

You could certainly do that. But why?

People would say they don't want to use it because it's not written 100% in Euphoria.
People would say they don't want to use it because Lazarus is a 160 meg download.
People would say they can't use it because it isn't simple enough.

No matter how easy to use you make it, someone will whine that "it's too hard..."

Even if you succeed in developing something that meets all the 'requirements' - remember that only a couple dozen people on the planet will actually use it. The rest will complain: "I typed 'make a game', but it didn't work!"

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

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

jmduro said...

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.

You say that, but then there's this:

irv said...

I suspect you've never had to change a few dozen or a few hundred lines of code because the customer decided he needed one more button or another label. I have one, written years ago with bare Eu and win32lib, that's still in use. Try browsing thru 7500 lines of code like the following, looking for an error in placement, and explain how that's easier!

That's just one problem with fixed positions and sizes. Another comes when your client decides he can't read the labels or list items easily, and insists on a larger font size. The third comes when he changes to a bigger monitor, and your program can't resize itself to fit the new screen. The fourth involves changing languages. So far, all my clients have been English speakers, but I do understand that sometimes Spanish captions can be longer than the English eqivalent, and no longer fit in the space you allotted.

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).

jmduro said...

Bouh hou, I cry! smile Everytime I want to do something with GTK, it is more complicated than expected. I hate sizers!

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.

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

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

jmduro said...

I hate sizers!

One day you will question why you ever said that.

-Greg

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

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

jimcbrown said...

While I agree with irv that sizers are easier and more hobbist friendly, not all UI libraries support it (notably, w32lib does not).

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?!

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

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

euphoric said...
jimcbrown said...

While I agree with irv that sizers are easier and more hobbist friendly, not all UI libraries support it (notably, w32lib does not).

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?!

I hated static positioning in Visual Basic. I would go so far as to argue that static positioning of widgets (controls) is technically incorrect user interface design. The reason is because it cannot correctly handle different fonts sizes or regional settings correctly. Besides that, why should i have to manually position stuff when the computer can do it much faster and more precisely?

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

Search



Quick Links

User menu

Not signed in.

Misc Menu