1. Unified libraries to allow porting code to other oses
- Posted by jmduro May 23, 2015
- 2963 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
2. Re: Unified libraries to allow porting code to other oses
- Posted by jimcbrown (admin) May 23, 2015
- 2974 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.
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.
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.
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.
3. Re: Unified libraries to allow porting code to other oses
- Posted by ryanj May 23, 2015
- 2883 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.
4. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 23, 2015
- 2921 views
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.
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.
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
5. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 23, 2015
- 2880 views
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.
6. Re: Unified libraries to allow porting code to other oses
- Posted by jimcbrown (admin) May 23, 2015
- 2973 views
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.
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.
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.
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.)
7. Re: Unified libraries to allow porting code to other oses
- Posted by ne1uno May 23, 2015
- 2880 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.
8. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 23, 2015
- 2837 views
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?
9. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 23, 2015
- 2868 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?
10. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 23, 2015
- 2846 views
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.
Jean-Marc
11. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 24, 2015
- 2784 views
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
12. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 24, 2015
- 2892 views
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
13. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 24, 2015
- 2863 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
14. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 24, 2015
- 2802 views
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
15. Re: Unified libraries to allow porting code to other oses
- Posted by Bazzadude May 24, 2015
- 2775 views
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.
16. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 24, 2015
- 2734 views
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?
17. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 24, 2015
- 2808 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.
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!
18. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 24, 2015
- 2781 views
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?
19. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 24, 2015
- 2761 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
20. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 25, 2015
- 2759 views
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
21. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 25, 2015
- 2710 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")
22. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 25, 2015
- 2762 views
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
23. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 25, 2015
- 2691 views
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.
24. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 26, 2015
- 2617 views
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?
25. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 27, 2015
- 2598 views
Hi Irv,
Is this wxWidgets 3? or the old 2.8?
It is based on wxEuphoria 0.1.7 which wraps the old wxWidgets 2.8.
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.
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
26. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 27, 2015
- 2558 views
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.
27. Re: Unified libraries to allow porting code to other oses
- Posted by _tom (admin) May 27, 2015
- 2628 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
28. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 27, 2015
- 2556 views
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.
29. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 27, 2015
- 2632 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.
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.
30. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 27, 2015
- 2561 views
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.
31. Re: Unified libraries to allow porting code to other oses
- Posted by irv May 27, 2015
- 2552 views
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.
32. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro May 27, 2015
- 2552 views
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.
The Trash 80 was my first computer but I'm still far from getting retired. I'm about to be 55.
33. Re: Unified libraries to allow porting code to other oses
- Posted by andi49 May 27, 2015
- 2561 views
[...]
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
34. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 04, 2015
- 2521 views
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
35. Re: Unified libraries to allow porting code to other oses
- Posted by irv Jun 05, 2015
- 2463 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.
36. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 05, 2015
- 2422 views
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
37. Re: Unified libraries to allow porting code to other oses
- Posted by irv Jun 05, 2015
- 2414 views
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.
38. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 06, 2015
- 2405 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.
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
39. Re: Unified libraries to allow porting code to other oses
- Posted by irv Jun 06, 2015
- 2363 views
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.
40. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 06, 2015
- 2389 views
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! 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?
41. Re: Unified libraries to allow porting code to other oses
- Posted by BRyan Jun 06, 2015
- 2348 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.
42. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 06, 2015
- 2375 views
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.
43. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 06, 2015
- 2353 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
44. Re: Unified libraries to allow porting code to other oses
- Posted by irv Jun 06, 2015
- 2410 views
Bouh hou, I cry! 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.
45. Re: Unified libraries to allow porting code to other oses
- Posted by jmduro Jun 06, 2015
- 2378 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.
46. Re: Unified libraries to allow porting code to other oses
- Posted by irv Jun 07, 2015
- 2357 views
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!"
47. Re: Unified libraries to allow porting code to other oses
- Posted by jimcbrown (admin) Jun 07, 2015
- 2313 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.
You say that, but then there's this:
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).
Bouh hou, I cry! 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.
48. Re: Unified libraries to allow porting code to other oses
- Posted by ghaberek (admin) Jun 08, 2015
- 2261 views
I hate sizers!
One day you will question why you ever said that.
-Greg
49. Re: Unified libraries to allow porting code to other oses
- Posted by euphoric (admin) Jun 08, 2015
- 2306 views
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?!
50. Re: Unified libraries to allow porting code to other oses
- Posted by ryanj Jun 08, 2015
- 2303 views
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?