wXWidgets

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

wXWidgets

Joe Armstrong-2
Hello,

Has anybody made a library of high level abstractions to be
used on-top of wxWidgets?

The wxWidget library is very low level - and many of the manual pages
say "see external documentation" and just point into the C++ documentation.

I took a quick peep at the canvas code in the demo/ex_canvas.erl
module. Code like this is horrible and I can imagine it to be a
rather straightford mapping of the equivalent code in C++.

When programming Erlang what I absolutely don't want to do
is "pretend I'm writing in C++" then painfully translate this into Erlang.

What I'd really like is the simplicity of TCL/TK or processing
for writing GUI software - or how about rebol?

Ten minutes of playing with rebol (from www.rebol.com)
was enough to convince me that the current way GUIs are
built is a total mess.

I get the impression that GUI programming is actually going
backwards - in the 80's there were systems build on languages
like TCL that did not need GByte downloads and complex IDEs.

Nowadays  a Graphics Library can easily be a GByte of code -
so what went wrong - in the 1980's and entire OS with graphics
was a few tens of MBytes ....

Cheers

/Joe
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Fred Youhanaie-2
Joe,

If you enjoy the simplicity of Tcl/Tk, why not write the GUI part as a Tcl/Tk based erlang port?

e.g. https://github.com/fredyouhanaie/portcl

Cheers,
f.


On 28/10/16 12:53, Joe Armstrong wrote:

> Hello,
>
> Has anybody made a library of high level abstractions to be
> used on-top of wxWidgets?
>
> The wxWidget library is very low level - and many of the manual pages
> say "see external documentation" and just point into the C++ documentation.
>
> I took a quick peep at the canvas code in the demo/ex_canvas.erl
> module. Code like this is horrible and I can imagine it to be a
> rather straightford mapping of the equivalent code in C++.
>
> When programming Erlang what I absolutely don't want to do
> is "pretend I'm writing in C++" then painfully translate this into Erlang.
>
> What I'd really like is the simplicity of TCL/TK or processing
> for writing GUI software - or how about rebol?
>
> Ten minutes of playing with rebol (from www.rebol.com)
> was enough to convince me that the current way GUIs are
> built is a total mess.
>
> I get the impression that GUI programming is actually going
> backwards - in the 80's there were systems build on languages
> like TCL that did not need GByte downloads and complex IDEs.
>
> Nowadays  a Graphics Library can easily be a GByte of code -
> so what went wrong - in the 1980's and entire OS with graphics
> was a few tens of MBytes ....
>
> Cheers
>
> /Joe
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Joe Armstrong-2
On Fri, Oct 28, 2016 at 2:30 PM, Fred Youhanaie <[hidden email]> wrote:

> Joe,
>
> If you enjoy the simplicity of Tcl/Tk, why not write the GUI part as a
> Tcl/Tk based erlang port?
>
> e.g. https://github.com/fredyouhanaie/portcl
>
> Cheers,
> f.
>
>
>
> On 28/10/16 12:53, Joe Armstrong wrote:
>>
>> Hello,
>>
>> Has anybody made a library of high level abstractions to be
>> used on-top of wxWidgets?
>>
>> The wxWidget library is very low level - and many of the manual pages
>> say "see external documentation" and just point into the C++
>> documentation.
>>
>> I took a quick peep at the canvas code in the demo/ex_canvas.erl
>> module. Code like this is horrible and I can imagine it to be a
>> rather straightford mapping of the equivalent code in C++.
>>
>> When programming Erlang what I absolutely don't want to do
>> is "pretend I'm writing in C++" then painfully translate this into Erlang.
>>
>> What I'd really like is the simplicity of TCL/TK or processing
>> for writing GUI software - or how about rebol?
>>
>> Ten minutes of playing with rebol (from www.rebol.com)
>> was enough to convince me that the current way GUIs are
>> built is a total mess.
>>
>> I get the impression that GUI programming is actually going
>> backwards - in the 80's there were systems build on languages
>> like TCL that did not need GByte downloads and complex IDEs.
>>
>> Nowadays  a Graphics Library can easily be a GByte of code -
>> so what went wrong - in the 1980's and entire OS with graphics
>> was a few tens of MBytes ....
>>
>> Cheers
>>
>> /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

zxq9-2
In reply to this post by Joe Armstrong-2
On 2016年10月28日 金曜日 13:53:45 Joe Armstrong wrote:
> Hello,
>
> Has anybody made a library of high level abstractions to be
> used on-top of wxWidgets?

Hi, Joe.

I have two tiny libraries that I have been slowly putting my most
common GUI abstractions into.

https://github.com/zxq9/zxWidgets
This is the GUI abstractions -- basically meta-widgets built from wx
parts. Like a yes/no modals that return actual booleans instead of
building one each time from buttons/images/references, and grid
structure boxes with headers and labels you can pass in as two lists
and get the constructed reference back (along with a function for
looping through the results, etc.). It is very basic and still lacks
some of the more interesting things I want to do (like 2D and 3D
paint frames within which abstract widget drawing functions can be
used -- basically taking a page out of game widget libs).

Jumptext [imaginary URL goes here]
This one does i18n, and they work together to refresh the skin,
text strings, manage the text strings, etc. It is still unreleased
because it is in a vague legal status (I wrote it, but do I own it if it
was on contract? etc). I will need the same thing later anyway, so I'll
probably wind up re-writing nearly the same thing again and putting it
up.

The glaring omission is the gen_gui behavior I've yet to include in
zxWidgets. There is a very straightforward pattern I've established
for getting the core wx bits up and running, and passing the unhandled
wx* messages through to a callback module, but I've just not gotten
around to formalizing it as a module yet. Which is silly of me, but
this is all unpaid work. :-(

> The wxWidget library is very low level - and many of the manual pages
> say "see external documentation" and just point into the C++ documentation.
>
> I took a quick peep at the canvas code in the demo/ex_canvas.erl
> module. Code like this is horrible and I can imagine it to be a
> rather straightford mapping of the equivalent code in C++.
>
> When programming Erlang what I absolutely don't want to do
> is "pretend I'm writing in C++" then painfully translate this into Erlang.

Yes. This complaint was my exact motivation for starting on zxWidgets.
Unfortunately the project that was paying for that party got put on hold
for a bit, but will probably be revived later.

I *really* want to provide a functional style lib over the 2D and 3D
canvass parts!

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Joe Armstrong-2
In reply to this post by Fred Youhanaie-2
Yup - actually I've been digging through my 10-15 year old TCL/TK stuff
which amazingly still works well - and is *way* simpler than wxWidgets

The canvas widget in HTML seems to be about the right level of
abstraction - actually all one needs is a widget that can draw things
using the SVG
path and group commands ...

/Joe



On Fri, Oct 28, 2016 at 2:30 PM, Fred Youhanaie <[hidden email]> wrote:

> Joe,
>
> If you enjoy the simplicity of Tcl/Tk, why not write the GUI part as a
> Tcl/Tk based erlang port?
>
> e.g. https://github.com/fredyouhanaie/portcl
>
> Cheers,
> f.
>
>
>
> On 28/10/16 12:53, Joe Armstrong wrote:
>>
>> Hello,
>>
>> Has anybody made a library of high level abstractions to be
>> used on-top of wxWidgets?
>>
>> The wxWidget library is very low level - and many of the manual pages
>> say "see external documentation" and just point into the C++
>> documentation.
>>
>> I took a quick peep at the canvas code in the demo/ex_canvas.erl
>> module. Code like this is horrible and I can imagine it to be a
>> rather straightford mapping of the equivalent code in C++.
>>
>> When programming Erlang what I absolutely don't want to do
>> is "pretend I'm writing in C++" then painfully translate this into Erlang.
>>
>> What I'd really like is the simplicity of TCL/TK or processing
>> for writing GUI software - or how about rebol?
>>
>> Ten minutes of playing with rebol (from www.rebol.com)
>> was enough to convince me that the current way GUIs are
>> built is a total mess.
>>
>> I get the impression that GUI programming is actually going
>> backwards - in the 80's there were systems build on languages
>> like TCL that did not need GByte downloads and complex IDEs.
>>
>> Nowadays  a Graphics Library can easily be a GByte of code -
>> so what went wrong - in the 1980's and entire OS with graphics
>> was a few tens of MBytes ....
>>
>> Cheers
>>
>> /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Joe Armstrong-2
In reply to this post by zxq9-2
On Fri, Oct 28, 2016 at 4:16 PM, zxq9 <[hidden email]> wrote:

> On 2016年10月28日 金曜日 13:53:45 Joe Armstrong wrote:
>> Hello,
>>
>> Has anybody made a library of high level abstractions to be
>> used on-top of wxWidgets?
>
> Hi, Joe.
>
> I have two tiny libraries that I have been slowly putting my most
> common GUI abstractions into.
>

Thanks - I shall take a look a most worthy effort ...

/Joe

> https://github.com/zxq9/zxWidgets
> This is the GUI abstractions -- basically meta-widgets built from wx
> parts. Like a yes/no modals that return actual booleans instead of
> building one each time from buttons/images/references, and grid
> structure boxes with headers and labels you can pass in as two lists
> and get the constructed reference back (along with a function for
> looping through the results, etc.). It is very basic and still lacks
> some of the more interesting things I want to do (like 2D and 3D
> paint frames within which abstract widget drawing functions can be
> used -- basically taking a page out of game widget libs).
>
> Jumptext [imaginary URL goes here]
> This one does i18n, and they work together to refresh the skin,
> text strings, manage the text strings, etc. It is still unreleased
> because it is in a vague legal status (I wrote it, but do I own it if it
> was on contract? etc). I will need the same thing later anyway, so I'll
> probably wind up re-writing nearly the same thing again and putting it
> up.
>
> The glaring omission is the gen_gui behavior I've yet to include in
> zxWidgets. There is a very straightforward pattern I've established
> for getting the core wx bits up and running, and passing the unhandled
> wx* messages through to a callback module, but I've just not gotten
> around to formalizing it as a module yet. Which is silly of me, but
> this is all unpaid work. :-(
>
>> The wxWidget library is very low level - and many of the manual pages
>> say "see external documentation" and just point into the C++ documentation.
>>
>> I took a quick peep at the canvas code in the demo/ex_canvas.erl
>> module. Code like this is horrible and I can imagine it to be a
>> rather straightford mapping of the equivalent code in C++.
>>
>> When programming Erlang what I absolutely don't want to do
>> is "pretend I'm writing in C++" then painfully translate this into Erlang.
>
> Yes. This complaint was my exact motivation for starting on zxWidgets.
> Unfortunately the project that was paying for that party got put on hold
> for a bit, but will probably be revived later.
>
> I *really* want to provide a functional style lib over the 2D and 3D
> canvass parts!
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Anthony Ramine-4
In reply to this post by Joe Armstrong-2
Replied below.

> Le 28 oct. 2016 à 13:53, Joe Armstrong <[hidden email]> a écrit :
>
> Ten minutes of playing with rebol (from www.rebol.com)
> was enough to convince me that the current way GUIs are
> built is a total mess.
>
> I get the impression that GUI programming is actually going
> backwards - in the 80's there were systems build on languages
> like TCL that did not need GByte downloads and complex IDEs.
>
> Nowadays  a Graphics Library can easily be a GByte of code -
> so what went wrong - in the 1980's and entire OS with graphics
> was a few tens of MBytes ....

In the 1980s each system had its own look'n'feel, its own set of keyboard shortcuts, etc etc.

I'm already annoyed when a text field isn't the system widget because some keybindings I'm accustomed too are missing, I just couldn't use an application of which the whole GUI is custom.

How many graphical systems in the 1980s that were powered by Tcl/Tk were usable by visually-impaired people?

How many of them came with a text-to-speech subsystem? How many of them could allow users to set a higher contrast or a higher aspect ratio?

> Le 28 oct. 2016 à 16:18, Joe Armstrong <[hidden email]> a écrit :
>
> The canvas widget in HTML seems to be about the right level of
> abstraction - actually all one needs is a widget that can draw things
> using the SVG
> path and group commands ...

The canvas widget means you just produce pixels. How can that be accessible?

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Richard A. O'Keefe-2
In reply to this post by Joe Armstrong-2


On 29/10/16 12:53 AM, Joe Armstrong wrote:
> I get the impression that GUI programming is actually going
> backwards - in the 80's there were systems build on languages
> like TCL that did not need GByte downloads and complex IDEs.

The first GUI interface I ever programmed was Interlisp-D,
which was Interlisp running on Xerox 1108s, 1109s, 1185s, and
1186s.  Everything above the microcode level was Lisp.  The
GUI library occupied two chapters in the manual, and from
never having programmed a GUI before it took me about 10 days
to get a multipane debugger going.  The machine had a 32MB
virtual memory and a 4MB physical memory, and it was a couple
of decades before I had access to a GUI that was as fast in
use.

 From that standpoint: Tcl/Tk is arcane and bloated. (:-)

One change: colour.  The later Xerox D-machines had colour
displays, the earlier ones didn't.
Another change: images.  The D-machines were *great* at
styled text (that's where the word processor was invented,
after all) and vector graphics.  They didn't (at least not
back in 1984) have to deal with a whole lot of image file
formats.
Another change: video.
Another change: 3D.
Another change: HTML support.  (Which used to work fine on 8MB Macs...)

The Interlisp-D GUI kit stayed small because it HAD to.
wxWidgets is big because it CAN be and the incremental cost
of expanding it is always less than the incremental cost (to
the developers) of shrinking it (which might require redesign).

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Steve Davis
In reply to this post by Joe Armstrong-2
Hi Joe,

I had a shot at making a “gs-style” interface for wx.

https://github.com/komone/gx

I got quite a long way, even to the point of being able to replace the generated code… but unfortunately didn’t get as far as writing documentation (yet?).

Still, may be of interest.

/s

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Joe Armstrong-2
In reply to this post by Richard A. O'Keefe-2
On Mon, Oct 31, 2016 at 5:28 AM, Richard A. O'Keefe <[hidden email]> wrote:

>
>
> On 29/10/16 12:53 AM, Joe Armstrong wrote:
>>
>> I get the impression that GUI programming is actually going
>> backwards - in the 80's there were systems build on languages
>> like TCL that did not need GByte downloads and complex IDEs.
>
>
> The first GUI interface I ever programmed was Interlisp-D,
> which was Interlisp running on Xerox 1108s, 1109s, 1185s, and
> 1186s.  Everything above the microcode level was Lisp.  The
> GUI library occupied two chapters in the manual, and from
> never having programmed a GUI before it took me about 10 days
> to get a multipane debugger going.  The machine had a 32MB
> virtual memory and a 4MB physical memory, and it was a couple
> of decades before I had access to a GUI that was as fast in
> use.
>
> From that standpoint: Tcl/Tk is arcane and bloated. (:-)
>
> One change: colour.  The later Xerox D-machines had colour
> displays, the earlier ones didn't.
> Another change: images.  The D-machines were *great* at
> styled text (that's where the word processor was invented,
> after all) and vector graphics.  They didn't (at least not
> back in 1984) have to deal with a whole lot of image file
> formats.
> Another change: video.
> Another change: 3D.
> Another change: HTML support.  (Which used to work fine on 8MB Macs...)
>
> The Interlisp-D GUI kit stayed small because it HAD to.
> wxWidgets is big because it CAN be and the incremental cost
> of expanding it is always less than the incremental cost (to
> the developers) of shrinking it (which might require redesign).

Brilliant - you are 100% correct - I'd never thought of it that way.

The marginal cost of adding a feature is low - and can be financed
by the people wanting the additional feature - if it is badly
implemented it won't really matter - since very few people initially
use new features.

The marginal cost of removing a feature is enormous - and will break
any code using the feature - so this does not get done.

In the good 'ol unix days features competed for disk space, and unused
new features were removed to save space - now there are no such restrictions.

Thus systems grow and grow until they become so brittle they cannot be
changed - at this point we wave a magic wand and bake them into a
virtual machine in some fancy container - and then start over.

So this is why something that used to be a few KBytes of code
is now wrapped up in the middle of a GByte download.

Our DNA is roughly 97% junk - evidence of earlier experiments gone
wrong - rather like modern software.

Niklas Wirth used to say that whenever we added a new feature to a system
we should remove some old feature - this is keep the system small, simple
and understandable - but their is no economic incentive to do so.

The soggy mess that we will end up with will be somebody else's
problem and we can happily say we are adding to employment prospects
in the future
by creating a mess that somebody else will clear up :-)

/Joe

>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Anthony Ramine-4

> Le 31 oct. 2016 à 16:55, Joe Armstrong <[hidden email]> a écrit :
>
> So this is why something that used to be a few KBytes of code
> is now wrapped up in the middle of a GByte download.

But you do realise that what you dismiss as bloat is just... way more features that were lacking and that you can't argue they should disappear, right?

I don't get the false comparison with the 80s systems where you just couldn't use said systems if you were disabled. Tcl/Tk was never made to work with screen readers and whatnot.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wXWidgets

Vans S
Interesting thread, may I butt in with a comment about how the GUI library is just that, to be ideally cross platform and to have widgets, gadgets and other pre-built things like tables.

But the real problem I have been encountering these days is how do you make your GUI represent your data, without tangling it in a mess of events, handlers and triggers.

On the GUI side of things I have toyed with observer pattern (backbone, knockout.js) > reactive model (react.js+redux) > clojurescript (reagent).  So far I have loved the one way reactive model, and clojurescript takes that to a new level.

The premise is that your GUI is "dumb" and cannot handle any events/triggers to check/uncheck a checkbox for example.  The only "smart" parts of your program are your state, and your actions/reductions/transitions/insert_fancy_term_here on that state (nicely modeled by using a gen_statem). Anytime the state changes, the GUI now needs to be redraw to reflect the change in state.  

Having just last week bumped head first into this problem yet again when working with a foreign code base.  The codebase did not use any observer/reactive patterns, everything on the GUI was triggered via a global event that could be called from any place in the code, and multiple parts of the UI could subscribe to the same global events, leading to a GUI that grew exponentially in complex as features were added.


On Monday, October 31, 2016 12:32 PM, Anthony Ramine <[hidden email]> wrote:



> Le 31 oct. 2016 à 16:55, Joe Armstrong <[hidden email]> a écrit :
>
> So this is why something that used to be a few KBytes of code
> is now wrapped up in the middle of a GByte download.

But you do realise that what you dismiss as bloat is just... way more features that were lacking and that you can't argue they should disappear, right?

I don't get the false comparison with the 80s systems where you just couldn't use said systems if you were disabled. Tcl/Tk was never made to work with screen readers and whatnot.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions