[julia-users] Re: the state of GUI toolkits?

[Jerzy Głowacki]

As for Gtk+, we have done an ECG signal analysis app 
 in Julia using Gtk.jl and it 
worked really well for us.

[julia-users] Re: the state of GUI toolkits?

[Cedric St-Jean]

 FWIW, I've been working on PyCall.jl to make it possible to define Python 
classes in Julia. That would enable a bunch of Python frameworks. I've 
found a work-around for my own use case so I haven't pushed it further, but 
if anyone cares about it, it'd be good to know.

On Wednesday, March 16, 2016 at 7:44:31 PM UTC-4, Jerzy Głowacki wrote:
>
> As for Gtk+, we have done an ECG signal analysis app 
>  in Julia using Gtk.jl and it 
> worked really well for us.
>

[julia-users] Re: the state of GUI toolkits?

[Tom Breloff]

I was thinking a little more about how to best implement a Qt5.jl module, 
without too much headache, and still letting you use the niceties of QML, 
etc.  Here's a rough outline of a possible design (please be brutal with 
your comments, and also let me know if you have interest working on this):


   - In julia, there is a *Qt5Manager* that controls the life-cycle and 
   communication with the gui (maybe over zmq?  The more isolated the gui, the 
   more flexible the framework.)
   - In C++ (or julia: Cxx)?  There's something which receives gui commands 
   over zmq and interacts with the gui.  On gui event callbacks, the relevant 
   info (callback name, params) are passed over zmq to julia, and are handled.
   - There are *exec* and *quit* methods which spin up the Qt event loop in 
   another thread or process, and set up zmq communication.
   - There are julia shortcuts to creating QML files, and automatic Qt app 
   building from within julia. (so you could call 
   *buildQtApp(QMLFile(/tmp/tmp.qml))* from within julia, and it would 
   return something that you could *exec*, automatically doing any 
   Qt-specific building/compiling/linking and creating a handle that the 
   manager could start up).  This is really just a wrapper to the Qt/C++ build 
   process.

I'd love to hear comments and expected issues with this sort of design, as 
well as if there are better methods of RPC between independent julia and 
C++ processes.   The clear benefit is that in theory, you only need to 1) 
wrap the Qt/C++ build process in a julia function, and 2) Create the julia 
and C++ endpoints to convert julia method calls to C++ method calls and 
vice versa, both over zmq.   We don't need to know (or wrap) all the 
functionality, just a way to generically translate to/from Qt 
methods/callbacks.  Another benefit is that you could potentially swap out 
either end, or broadcast commands to multiple guis (for example, powering a 
remote web app with node/javascript while updating a local qt instance, or 
creating collaboration tools with multiple UIs sharing the same state)... 
all with simple changes to the sockets.  Here's how I'd imagine the julia 
user code:

using Qt5
gui = buildQtApp(QML(/tmp/helloworld.qml))

myhandler(gui, args...) = gui[:setTitle](Hello World) 
connect(gui, :clicked, mybutton, myhandler)

exec(gui)




On Saturday, May 2, 2015 at 4:38:00 AM UTC-4, Steven Sagaert wrote:

 Another way (maybe conceptually the nicest) would be to look an how the Qt 
 team integrated the QML/javascript VM with the Qt C++ code and do the 
 analog thing for the julia runtime. QML would then be replaced by Julia (or 
 a julia based DSL e.g. via macros).
 The advantage would be that you don't have to export the julia code that 
 you want to call from the GUI to Qt since the GUI is in julia.
 The disadvantage is that you loose the ability to design the GUI 
 graphically via the design tool.

 On Friday, May 1, 2015 at 2:58:06 PM UTC+2, Tom Breloff wrote:

 Steven... can you post a summary of how you would ideally interact with 
 Qt5.jl?  I assume you'd want clean syntax to define a gui with a QML string 
 (or file), along with clean syntax to define signals/slots to connect to 
 julia callbacks.  Could you post some simple/hypothetical code that you 
 would ideally call from within julia?  This will help as I'm reading the 
 Qt5 docs.  Thanks.

 On Friday, May 1, 2015 at 4:59:43 AM UTC-4, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it 
 old school by calling a bunch of julia functions/methods that wrap the 
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped. 
 However if you stick to the new school approach i.e. QtQuick + QML then a 
 lot less C++ classes need to be wrapped and GUI construction would 
 basically be writing QML string and passing them from julia onto the Qt5 
 side which then interprets it. So it that sense it's not that different 
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. 
 Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

Re: [julia-users] Re: the state of GUI toolkits?

[Isaiah Norton]

 I'd love to hear comments and expected issues with this sort of design


Performance is one --  IMHO that is the primary reason to use Qt over a
JavaScript UI. If you are going to be routing stuff over socket RPC anyway
then I don't see much point in using Qt instead of node-webkit/CEF and all
the JavaScript goodies that Shashi, Mike, and Co. are building. (React,
Blink, etc.).

On Fri, May 29, 2015 at 10:07 AM, Tom Breloff t...@breloff.com wrote:

 I was thinking a little more about how to best implement a Qt5.jl module,
 without too much headache, and still letting you use the niceties of QML,
 etc.  Here's a rough outline of a possible design (please be brutal with
 your comments, and also let me know if you have interest working on this):


- In julia, there is a *Qt5Manager* that controls the life-cycle and
communication with the gui (maybe over zmq?  The more isolated the gui, the
more flexible the framework.)
- In C++ (or julia: Cxx)?  There's something which receives gui
commands over zmq and interacts with the gui.  On gui event callbacks, the
relevant info (callback name, params) are passed over zmq to julia, and are
handled.
- There are *exec* and *quit* methods which spin up the Qt event loop
in another thread or process, and set up zmq communication.
- There are julia shortcuts to creating QML files, and automatic Qt
app building from within julia. (so you could call
*buildQtApp(QMLFile(/tmp/tmp.qml))* from within julia, and it would
return something that you could *exec*, automatically doing any
Qt-specific building/compiling/linking and creating a handle that the
manager could start up).  This is really just a wrapper to the Qt/C++ build
process.

 I'd love to hear comments and expected issues with this sort of design, as
 well as if there are better methods of RPC between independent julia and
 C++ processes.   The clear benefit is that in theory, you only need to 1)
 wrap the Qt/C++ build process in a julia function, and 2) Create the julia
 and C++ endpoints to convert julia method calls to C++ method calls and
 vice versa, both over zmq.   We don't need to know (or wrap) all the
 functionality, just a way to generically translate to/from Qt
 methods/callbacks.  Another benefit is that you could potentially swap out
 either end, or broadcast commands to multiple guis (for example, powering a
 remote web app with node/javascript while updating a local qt instance, or
 creating collaboration tools with multiple UIs sharing the same state)...
 all with simple changes to the sockets.  Here's how I'd imagine the julia
 user code:

 using Qt5
 gui = buildQtApp(QML(/tmp/helloworld.qml))

 myhandler(gui, args...) = gui[:setTitle](Hello World)
 connect(gui, :clicked, mybutton, myhandler)

 exec(gui)




 On Saturday, May 2, 2015 at 4:38:00 AM UTC-4, Steven Sagaert wrote:

 Another way (maybe conceptually the nicest) would be to look an how the
 Qt team integrated the QML/javascript VM with the Qt C++ code and do the
 analog thing for the julia runtime. QML would then be replaced by Julia (or
 a julia based DSL e.g. via macros).
 The advantage would be that you don't have to export the julia code that
 you want to call from the GUI to Qt since the GUI is in julia.
 The disadvantage is that you loose the ability to design the GUI
 graphically via the design tool.

 On Friday, May 1, 2015 at 2:58:06 PM UTC+2, Tom Breloff wrote:

 Steven... can you post a summary of how you would ideally interact with
 Qt5.jl?  I assume you'd want clean syntax to define a gui with a QML string
 (or file), along with clean syntax to define signals/slots to connect to
 julia callbacks.  Could you post some simple/hypothetical code that you
 would ideally call from within julia?  This will help as I'm reading the
 Qt5 docs.  Thanks.

 On Friday, May 1, 2015 at 4:59:43 AM UTC-4, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it
 old school by calling a bunch of julia functions/methods that wrap the
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped.
 However if you stick to the new school approach i.e. QtQuick + QML then a
 lot less C++ classes need to be wrapped and GUI construction would
 basically be writing QML string and passing them from julia onto the Qt5
 side which then interprets it. So it that sense it's not that different
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a
 good strategy for wrapping Qt5 with Cxx. The core functionality of Qt5
 (shared by Qt4) would be an obvious place to start.  The part that is
 clearly daunting is the interface for event handling, namely signals and
 slots. Not only we have to deal with/replace the underlying XML support,
 but also the syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Andreas Lobinger]

Hello colleagues,

just a few words. I started the thread to get an overview of what's 
available and to decide for myself where i'll spend time (when available).
And it's interesting what others perceive as possible solutions.

I think the main part of the story is: We still need more infrastucture in 
julia like Clang.jl/Cxx.jl and any FFI to automate the process of attaching 
to any external library. 

On the weekend it took me some hours to get Cxx -actually a 0.4 with local 
LLVM3.7- compiled and running. Then the supplied Qt example worked (afaics 
it opens a window) (along that i learned something about the systen 
independences of Qt and X11 and window managers...).
So if you want spend time on interfacing Qt, just get your CXX working take 
and Qt manual and hack away. Some people might argue their programming 
skills are not enough, but believe me: Julia is a quite nice laboratory for 
library interfacing. 

[julia-users] Re: the state of GUI toolkits?

[Andreas Lobinger]

So if you want spend time on interfacing Qt, just get your CXX working and 
take your Qt manual and hack away. Some people might argue their 
programming skills are not enough, but believe me: Julia is a quite nice 
laboratory for library interfacing. 

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

Another way (maybe conceptually the nicest) would be to look an how the Qt 
team integrated the QML/javascript VM with the Qt C++ code and do the 
analog thing for the julia runtime. QML would then be replaced by Julia (or 
a julia based DSL e.g. via macros).
The advantage would be that you don't have to export the julia code that 
you want to call from the GUI to Qt since the GUI is in julia.
The disadvantage is that you loose the ability to design the GUI 
graphically via the design tool.

On Friday, May 1, 2015 at 2:58:06 PM UTC+2, Tom Breloff wrote:

 Steven... can you post a summary of how you would ideally interact with 
 Qt5.jl?  I assume you'd want clean syntax to define a gui with a QML string 
 (or file), along with clean syntax to define signals/slots to connect to 
 julia callbacks.  Could you post some simple/hypothetical code that you 
 would ideally call from within julia?  This will help as I'm reading the 
 Qt5 docs.  Thanks.

 On Friday, May 1, 2015 at 4:59:43 AM UTC-4, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it 
 old school by calling a bunch of julia functions/methods that wrap the 
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped. 
 However if you stick to the new school approach i.e. QtQuick + QML then a 
 lot less C++ classes need to be wrapped and GUI construction would 
 basically be writing QML string and passing them from julia onto the Qt5 
 side which then interprets it. So it that sense it's not that different 
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

The idea would be to describe the GUI  it's behavior via QML/javascript. 
Any julia modules/functions (event handlers) that need to be called from 
the GUI could be exported as C++ QtObjects/methods (that's the hard part). 
These can then be called from QML. Passing the QML to Qt  interpreting it 
would be done by wrapping the QtQML C++ code with julia code. 

On Friday, May 1, 2015 at 2:58:06 PM UTC+2, Tom Breloff wrote:

 Steven... can you post a summary of how you would ideally interact with 
 Qt5.jl?  I assume you'd want clean syntax to define a gui with a QML string 
 (or file), along with clean syntax to define signals/slots to connect to 
 julia callbacks.  Could you post some simple/hypothetical code that you 
 would ideally call from within julia?  This will help as I'm reading the 
 Qt5 docs.  Thanks.

 On Friday, May 1, 2015 at 4:59:43 AM UTC-4, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it 
 old school by calling a bunch of julia functions/methods that wrap the 
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped. 
 However if you stick to the new school approach i.e. QtQuick + QML then a 
 lot less C++ classes need to be wrapped and GUI construction would 
 basically be writing QML string and passing them from julia onto the Qt5 
 side which then interprets it. So it that sense it's not that different 
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

One could of course let Qt/C++ be in charge as he main loop and just run 
julia as an embedded engine and expose the julia functionality one wants to 
call as QtObjects  methods so that these can be called from QML.

On Friday, May 1, 2015 at 3:49:12 PM UTC+2, Steven Sagaert wrote:

 The idea would be to describe the GUI  it's behavior via QML/javascript. 
 Any julia modules/functions (event handlers) that need to be called from 
 the GUI could be exported as C++ QtObjects/methods (that's the hard part). 
 These can then be called from QML. Passing the QML to Qt  interpreting it 
 would be done by wrapping the QtQML C++ code with julia code. 

 On Friday, May 1, 2015 at 2:58:06 PM UTC+2, Tom Breloff wrote:

 Steven... can you post a summary of how you would ideally interact with 
 Qt5.jl?  I assume you'd want clean syntax to define a gui with a QML string 
 (or file), along with clean syntax to define signals/slots to connect to 
 julia callbacks.  Could you post some simple/hypothetical code that you 
 would ideally call from within julia?  This will help as I'm reading the 
 Qt5 docs.  Thanks.

 On Friday, May 1, 2015 at 4:59:43 AM UTC-4, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it 
 old school by calling a bunch of julia functions/methods that wrap the 
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped. 
 However if you stick to the new school approach i.e. QtQuick + QML then a 
 lot less C++ classes need to be wrapped and GUI construction would 
 basically be writing QML string and passing them from julia onto the Qt5 
 side which then interprets it. So it that sense it's not that different 
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. 
 Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

I think it depends how you want to build the GUI: if you want to do it old 
school by calling a bunch of julia functions/methods that wrap the C++ 
methods than yes a lot of C++ classes/methods will need to be wrapped. 
However if you stick to the new school approach i.e. QtQuick + QML then a 
lot less C++ classes need to be wrapped and GUI construction would 
basically be writing QML string and passing them from julia onto the Qt5 
side which then interprets it. So it that sense it's not that different 
from say writing an SQL library wrapper like ODBC.

On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

The advantage of doing the modern way is that you then can also use GUI 
design tools like Qt Quick designer to graphically do your GUI layout, let 
it generate QML and you can just copy paste that into your julia GUI code.

On Friday, May 1, 2015 at 10:59:43 AM UTC+2, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it 
 old school by calling a bunch of julia functions/methods that wrap the 
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped. 
 However if you stick to the new school approach i.e. QtQuick + QML then a 
 lot less C++ classes need to be wrapped and GUI construction would 
 basically be writing QML string and passing them from julia onto the Qt5 
 side which then interprets it. So it that sense it's not that different 
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Andreas Lobinger]

just for the record:

On Friday, May 1, 2015 at 11:07:53 AM UTC+2, Steven Sagaert wrote:

 The advantage of doing the modern way is that you then can also use GUI 
 design tools like Qt Quick designer to graphically do your GUI layout, let 
 it generate QML and you can just copy paste that into your julia GUI code.


gtkBuilder + glade exist:
 https://developer.gnome.org/gtk3/stable/GtkBuilder.html
 https://glade.gnome.org/

for some time...

[julia-users] Re: the state of GUI toolkits?

[Alex]

Hi together,

Although this is slightly off-topic I wanted to throw FLTK 
http://www.fltk.org/index.php into the ring. It is certainly not as 
modern as Qt5, but it is fast and light! One also needs Cxx.jl since FLTK 
is a C++ library, but it is pretty conservative (no templates etc), so it 
shouldn't be too hard to wrap it (I can post some proof of principle code, 
but my Cxx is currently broken, so I can't test it further).

Anyways, I think the topic of widget toolkits can be very subjective and 
controversial. I just wanted to mention FLTK as an option, but definitely 
don't want to start a fundamental discussion about different WTKs.

Best,

Alex.

[julia-users] Re: the state of GUI toolkits?

[Tom Breloff]

Steven... can you post a summary of how you would ideally interact with 
Qt5.jl?  I assume you'd want clean syntax to define a gui with a QML string 
(or file), along with clean syntax to define signals/slots to connect to 
julia callbacks.  Could you post some simple/hypothetical code that you 
would ideally call from within julia?  This will help as I'm reading the 
Qt5 docs.  Thanks.

On Friday, May 1, 2015 at 4:59:43 AM UTC-4, Steven Sagaert wrote:

 I think it depends how you want to build the GUI: if you want to do it 
 old school by calling a bunch of julia functions/methods that wrap the 
 C++ methods than yes a lot of C++ classes/methods will need to be wrapped. 
 However if you stick to the new school approach i.e. QtQuick + QML then a 
 lot less C++ classes need to be wrapped and GUI construction would 
 basically be writing QML string and passing them from julia onto the Qt5 
 side which then interprets it. So it that sense it's not that different 
 from say writing an SQL library wrapper like ODBC.

 On Thursday, April 30, 2015 at 10:59:32 PM UTC+2, Max Suster wrote:

 Good to hear interest. I will also have to look at what might be a good 
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared 
 by Qt4) would be an obvious place to start.  The part that is clearly 
 daunting is the interface for event handling, namely signals and slots. Not 
 only we have to deal with/replace the underlying XML support, but also the 
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

It's been a long since I looked at Gtk in any detail so I kind of forgot 
about Glade but after taking a quick look it seems the Glade XML is only 
about the structure and not about behaviour. QML also also allows to 
describe behaviour so more versatile AFAIK.

On Friday, May 1, 2015 at 12:31:16 PM UTC+2, Andreas Lobinger wrote:

 just for the record:

 On Friday, May 1, 2015 at 11:07:53 AM UTC+2, Steven Sagaert wrote:

 The advantage of doing the modern way is that you then can also use GUI 
 design tools like Qt Quick designer to graphically do your GUI layout, let 
 it generate QML and you can just copy paste that into your julia GUI code.


 gtkBuilder + glade exist:
  https://developer.gnome.org/gtk3/stable/GtkBuilder.html
  https://glade.gnome.org/

 for some time...

[julia-users] Re: the state of GUI toolkits?

[Max Suster]

I too would love to have a Qt5.jl package.  Having such a robust and 
cross-platform GUI interface would make many projects more attractive to 
(non-expert) outsiders coming into Julia. I have been meaning to find time for 
this, but wrapping the whole of Qt5 alone is quite a project. . . Perhaps, if 
several people contributed, however, this might be more realistic in the 
shorter term?

[julia-users] Re: the state of GUI toolkits?

[Tom Breloff]

I would consider contributing, since I 1) would like to use it, and 2) want 
to learn more about integrating with C++.  My problem is that I've never 
seen or used Qt5 before, only Qt4.  So I'd need someone else to take the 
lead.

On Thursday, April 30, 2015 at 12:34:13 PM UTC-4, Max Suster wrote:

 I too would love to have a Qt5.jl package.  Having such a robust and 
 cross-platform GUI interface would make many projects more attractive to 
 (non-expert) outsiders coming into Julia. I have been meaning to find time 
 for this, but wrapping the whole of Qt5 alone is quite a project. . . 
 Perhaps, if several people contributed, however, this might be more 
 realistic in the shorter term? 

Re: [julia-users] Re: the state of GUI toolkits?

[Isaiah Norton]

 The part that is clearly daunting is the interface for event handling,
 namely signals and slots.


There is a WIP clang plugin designed to replace moc. Worth keeping an eye
on.
https://github.com/woboq/moc-ng

On Thu, Apr 30, 2015 at 4:59 PM, Max Suster mxsst...@gmail.com wrote:

 Good to hear interest. I will also have to look at what might be a good
 strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared
 by Qt4) would be an obvious place to start.  The part that is clearly
 daunting is the interface for event handling, namely signals and slots. Not
 only we have to deal with/replace the underlying XML support, but also the
 syntax has changed a lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[Max Suster]

Good to hear interest. I will also have to look at what might be a good 
strategy for wrapping Qt5 with Cxx. The core functionality of Qt5 (shared by 
Qt4) would be an obvious place to start.  The part that is clearly daunting is 
the interface for event handling, namely signals and slots. Not only we have to 
deal with/replace the underlying XML support, but also the syntax has changed a 
lot between Qt4 and Qt5.

[julia-users] Re: the state of GUI toolkits?

[J Luis]

I am also very interested in GUI tools and will be willing to contribute, 
so my  knowledge will allow. I have no experience whatsoever with Qt and 
every time I looked at it the feeling was not ... warm.
Some of you may remember my attempt on this matter with IUP. IUP looks nice 
and very fast on Windows but lacks an worrying lack of upstream 
tutorials/documentation. I will insist a bit more on IUP but if a Qt(X) 
solution starts to build up I'll be interested to participate.

quinta-feira, 30 de Abril de 2015 às 17:34:13 UTC+1, Max Suster escreveu:

 I too would love to have a Qt5.jl package.  Having such a robust and 
 cross-platform GUI interface would make many projects more attractive to 
 (non-expert) outsiders coming into Julia. I have been meaning to find time 
 for this, but wrapping the whole of Qt5 alone is quite a project. . . 
 Perhaps, if several people contributed, however, this might be more 
 realistic in the shorter term? 

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

I'd love to see a Qt5/QML wrapper. I find Qt5 superior to Gtk. Also it's 
available on more platforms (mobile).

On Tuesday, April 28, 2015 at 9:46:52 AM UTC+2, Andreas Lobinger wrote:

 Hello colleagues,

 what is status of availability and usecases for GUI toolkits.

 I see Tk and Gtk on the pkg.julialang.org. Gtk has the tag 'doesn't load' 
 from testing, Tk seems OK.
 In a recent discussion here, Tim Holy mentioned himself tesing Qwt and Qt 
 in general seem to be a testcase for Cxx.

 Do i miss something here?

 Wishing a happy day,
  Andreas

[julia-users] Re: the state of GUI toolkits?

[Tom Breloff]

I'm curious... what are the advantages of Qt5 over Qt4?  Is there 
functionality missing from Qt4?

On Wednesday, April 29, 2015 at 3:52:40 AM UTC-4, Steven Sagaert wrote:

 I'd love to see a Qt5/QML wrapper. I find Qt5 superior to Gtk. Also it's 
 available on more platforms (mobile).

 On Tuesday, April 28, 2015 at 9:46:52 AM UTC+2, Andreas Lobinger wrote:

 Hello colleagues,

 what is status of availability and usecases for GUI toolkits.

 I see Tk and Gtk on the pkg.julialang.org. Gtk has the tag 'doesn't 
 load' from testing, Tk seems OK.
 In a recent discussion here, Tim Holy mentioned himself tesing Qwt and Qt 
 in general seem to be a testcase for Cxx.

 Do i miss something here?

 Wishing a happy day,
  Andreas

[julia-users] Re: the state of GUI toolkits?

[Steven Sagaert]

There is a BIG difference between Qt4  Qt5. Qt4 is old school: the whole 
GU has to be programmed in C++. Qt5 is new school: you can declaratively 
specify the GUI  behavior via QML (basically javascript)  QtQuick 
classes. See https://wiki.qt.io/Qt_5. The old school way of doing 
everything in C++ is still available though.

Note that e.g. Ubuntu who was hardcore Gtk has also switched to Qt5 for 
their new versions because of the greater power/flexibility/platform range 
of Qt5 vs Gtk.

On Wednesday, April 29, 2015 at 3:30:09 PM UTC+2, Tom Breloff wrote:

 I'm curious... what are the advantages of Qt5 over Qt4?  Is there 
 functionality missing from Qt4?

 On Wednesday, April 29, 2015 at 3:52:40 AM UTC-4, Steven Sagaert wrote:

 I'd love to see a Qt5/QML wrapper. I find Qt5 superior to Gtk. Also it's 
 available on more platforms (mobile).

 On Tuesday, April 28, 2015 at 9:46:52 AM UTC+2, Andreas Lobinger wrote:

 Hello colleagues,

 what is status of availability and usecases for GUI toolkits.

 I see Tk and Gtk on the pkg.julialang.org. Gtk has the tag 'doesn't 
 load' from testing, Tk seems OK.
 In a recent discussion here, Tim Holy mentioned himself tesing Qwt and 
 Qt in general seem to be a testcase for Cxx.

 Do i miss something here?

 Wishing a happy day,
  Andreas