Julia IDE

[Tobi]

Hi,

just wanted to share that I am working on an IDE for Julia written in Julia with the Gtk.jl package. It has the code-name "Julietta" but I am open for suggestions regarding the final name.
Developement takes place as https://github.com/tknopp/Julietta.jl.
It should run on OSX/Windows/Linux given that one gets the Gtk package and GtkSourceView package installed.

In its current form it is not really usable but I would not have thought that I would get that far in a very short time period.
I would love to get some input of Julia developers on the following topics:

- I am not really sure how the best interaction is between GUI and the Julia terminal. I am currently using addprocs(1) and let all code run using remotecall. An alternative would be to run the REPL in an completely independent process and communicate via e.g. sockets. Is there a preferred way to do this?

- In general I would like to collect ideas on features what this IDE should can and how it should be designed.

Cheers,

Tobi

[Stefan Karpinski]

Very cool. I like that it's all written in Julia :-)

I think that the addprocs approach is great. You can even start a julia process on a remote system that way and interact with it through your IDE, which is pretty cool. You could potentially build an IDE that can easily do remote editing quite easily that way too.

I don't generally use IDEs, but this project excites me.

[Gour]

On Thu, 6 Feb 2014 09:09:01 -0800 (PST)
Tobi <tobias...@googlemail.com> wrote:

Hello,

> just wanted to share that I am working on an IDE for Julia written in
> Julia with the Gtk.jl package. It has the code-name "Julietta" but I
> am open for suggestions regarding the final name.

I'm considering whether Julia could serve me instead or along with
Python to create multi-platform GUI app.

Considering that there is PyCall.jl with support for GTK+ as well as Qt/
wx (which are, imho) more suitable for multi-platform app like Julietta
(btw, I like the name), I'm curious why you didn't opt to use Qt/ wx
and PyCall?


Sincerely,
Gour

--
As the ignorant perform their duties with attachment to results,
the learned may similarly act, but without attachment, for the
sake of leading people on the right path.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Stefan Karpinski]

It wasn't my decision, but Qt seems very hard to wrap since it's a C++ library and worse still, it uses custom C++ syntax extensions extensively. I'm not super clear on whether there is any C-callable Qt ABI or not. I suspect there isn't.

[Tobi]

Am Donnerstag, 6. Februar 2014 19:23:50 UTC+1 schrieb Gour:

I'm considering whether Julia could serve me instead or along with
Python to create multi-platform GUI app.

Considering that there is PyCall.jl with support for GTK+ as well as Qt/
wx (which are, imho) more suitable for multi-platform app like Julietta
(btw, I like the name), I'm curious why you didn't opt to use Qt/ wx
and PyCall?

This is simple to answer: I fell in love with Julia so why should I use another language?

More seriously: I started with this to explore whether Julia is a good fit for GUI programming. I have quite some experience with WPF/C# and have to say that Gtk.jl is seriously getting an absolute awesome package. Various things are in flux and missing  but what is there is really cool. And when something is missing in Gtk.jl one can simply contribute a patch.

Some further points:

- Julia code is jited which means that Gtk.jl code runs in native speed after first compilation

- I don't want to have to much dependencies

- As Stefan outlined, Qt is a complicated thing because it is C++. Gtk.jl is in large parts automatically generated from the C headers using Clang.jl.

I first also had concerns regarding the cross-platform capabilities of Gtk3 but I run it successfully on OSX and Windows.

 

[Gour]

On Thu, 6 Feb 2014 14:05:17 -0500
Stefan Karpinski <ste...@karpinski.org> wrote:

> It wasn't my decision, but Qt seems very hard to wrap since it's a C++
> library and worse still, it uses custom C++ syntax extensions
> extensively.

I'm very well aware of this problem and when inspecting several language
as potential candidates (from Haskell to OCaml, D, Ada, Rust, F#,
Nimrod...), more or less, everywhere it's the same situation - only
GTK+ bindings provided while Qt/wx are missing.

Some (e.g. Rust, Haskell, OCaml) try to e.g. use some kind of wxC, while
there is some work in OCaml on Qt bindings (lablqt) project.

So, it's not wonder that C++ still rules in that arena.

As far as Julia is concerned, it probably does not compete with C++,
but more with Python and here Python rules having GUI bindings for
practically everything, so my point is if it's possible for Python, why
not Julia (accepting the fact it's not easy) ?



Sincerely,
Gour

--
Not by merely abstaining from work can one achieve freedom
from reaction, nor by renunciation alone can one attain perfection.

[Gour]

On Thu, 6 Feb 2014 11:50:35 -0800 (PST)
Tobi <tobias...@googlemail.com> wrote:

> This is simple to answer: I fell in love with Julia so why should I
> use another language?

Heh, I did not mean 'another language', just 'another bindings'. :-)

> More seriously: I started with this to explore whether Julia is a
> good fit for GUI programming.

That's exactly what I'm trying to deduce. Does it make sense to learn
and use Julia instead of Python or some more statically-typed langauge
(from the set I reference in the reply to Stefan).

> - Julia code is jited which means that Gtk.jl code runs in native
> speed after first compilation

That's strong one, indeed.

> - As Stefan outlined, Qt is a complicated thing because it is C++.
> Gtk.jl is in large parts automatically generated from the C headers
> using Clang.jl.

That's true, but GTK looks ugly on everything non-Linux and the devs are
not very enthusiastic to support practically anything non-GNOME.

What about wx? It uses native widgets and looks much better.

> I first also had concerns regarding the cross-platform capabilities
> of Gtk3 but I run it successfully on OSX and Windows.

Nice to hear that you have good experience, but after seeing the
presentation (you can read about it here: http://lwn.net/Articles/562856/ )
I'm very firm not to use GTK for multi-platform project and, yes, I'm not into
web apps, at least not for the desktop ones. :-)

There are also lots of projects moving away from GTK.

Still, I wish you all the best with the project.


Sincerely,
Gour

--
Those who are on this path are resolute in purpose,
and their aim is one. O beloved child of the Kurus,
the intelligence of those who are irresolute is many-branched.

[Tobi]

Am Freitag, 7. Februar 2014 09:20:59 UTC+1 schrieb Gour:

That's exactly what I'm trying to deduce. Does it make sense to learn
and use Julia instead of Python or some more statically-typed langauge
(from the set I reference in the reply to Stefan).

For me Julia is both a Python and a C++ replacement. The ability to specify the type and dispatch on it is like programming in C++ without all the hassles.
And multiple-dispatch is really a great advantage of Julia compared to Python.

> - Julia code is jited which means that Gtk.jl code runs in native
> speed after first compilation

That's strong one, indeed.

Yep. Python is so often seen as a great "prototype language". Julia is different: Great for prototyping but also great for making robust fast programs. We are not finally there in various aspects (e.g. module precompilation) but I start to imagine that Julia is going to have a very bright future. At this point it might be "risky" to step on board. But if not you will miss the exciting journey :-)

That's true, but GTK looks ugly on everything non-Linux and the devs are
not very enthusiastic to support practically anything non-GNOME.

Partly true. But:
- After changing the theme on OSX it actually looks quite good (I can post a recent screenshot later)
- There is simply no other alternative. Qt with C++ is really problematic.
- Beeing a C-library makes Gtk also better distributable

 

What about wx? It uses native widgets and looks much better.

Wx is also C++. Don't know if they have a C-API

Nice to hear that you have good experience, but after seeing the
presentation (you can read about it here: http://lwn.net/Articles/562856/ )
I'm very firm not to use GTK for multi-platform project and, yes, I'm not into
web apps, at least not for the desktop ones. :-)

I am aware of that and the main issue seems to be that Gtk has not enough contributors.
Still, I now use Gtk+3.6 on Windows and Gtk3.10 on OSX and it seems to run quite well.
If Julia with Gtk.jl gets some momentum, we might also improve Gtk+ cross-platform capabilities upstream.
This is all better than wrapping a C++ library :-)

 

There are also lots of projects moving away from GTK.

I know one that is moving towards it :-)

 

Still, I wish you all the best with the project.

Thanks

 

[Gour]

On Fri, 7 Feb 2014 00:54:32 -0800 (PST)
Tobi <tobias...@googlemail.com> wrote:

> For me Julia is both a Python and a C++ replacement. The ability to
> specify the type and dispatch on it is like programming in C++
> without all the hassles.
> And multiple-dispatch is really a great advantage of Julia compared
> to Python.

It's all true.

> Yep. Python is so often seen as a great "prototype language". Julia
> is different: Great for prototyping but also great for making robust
> fast programs. We are not finally there in various aspects (e.g.
> module precompilation) but I start to imagine that Julia is going to
> have a very bright future. At this point it might be "risky" to step
> on board. But if not you will miss the exciting journey :-)

I'm not afraid of jumping on the ship language-wise, but GUI-bindings
wise. :-)

> - After changing the theme on OSX it actually looks quite good (I can
> post a recent screenshot later)

No need. Just ask Mac users (I'm not), how they like GTK on their OS. ;)

> - There is simply no other alternative. Qt with C++ is really
> problematic.

Why is it not for Python?

> Wx is also C++. Don't know if they have a C-API

wxHaskell projects has it.

> I am aware of that and the main issue seems to be that Gtk has not
> enough contributors.

And those seems to be hostile to scare people away.

> If Julia with Gtk.jl gets some momentum, we might also improve Gtk+
> cross-platform capabilities upstream.

We know who controls GTK, so I'll not hold my breath.

> This is all better than wrapping a C++ library :-)

Well, C++ wrapping is not easy, but it's long-term gain.

> > There are also lots of projects moving away from GTK.
> >
>
> I know one that is moving towards it :-)

I should say 'migrating'. Even DEs like LXDE are moving to Qt. You're
probably aware what Linus Torvalds thinks about C++, but even the
project (Subsurface) which was started by himself moved to Qt - see
instructive presentation: https://www.youtube.com/watch?v=ON0A1dsQOV0

But, of course, it's your project and you can do whatever you like. I
just wanted to give you a hint sparing you from possible future
rewrite. ;)


Sincerely,
Gour

--
As the embodied soul continuously passes, in this body,
from boyhood to youth to old age, the soul similarly passes
into another body at death. A sober person is not bewildered
by such a change.

[Tobi]

I understand all your concerns. If someone wants too wrap Qt in Julia this would be great.
But I have decided that I would not do it as this is serious and challenging work.

Gtk and Julia fit very nicely together (implementation wise). And the look is from my perspective ok.
This is (currently) a fun project to look how far I come. And getting thus far in two weeks spare time work isn't what I have imagined.
I want to put more energy into things like "code completion", "jump to function definition on right click", and so on instead of thinking about the appearance of my widgets.

In my day job I work with VisualStudio/C#. And VS is simply such a great IDE that I am missing it all the time when I program in Julia.

[Tim Holy]

Gour, if you'd like to start a Qt.jl package, that would be great. If you
succeeded in overcoming the major hurdles, I suspect there would be
considerable interest. (The reason I started Cpp.jl was in part aiming towards
Qt.) Given that Python has wrapped Qt, I agree it's surely possible for Julia
as well. But keep in mind that Python has been around a long time, has gone
through several iterations of Qt wrappers, and collectively those wrappers
have had probably tens-of-thousands of human-hours thrown at them (including
corporate-sponsored hours). In contrast, Gtk.jl is basically the work of 4
people (of whom Jameson is by far the most significant), and it's extraordinary
how _pretty_ the guts of it are and how productive that effort has been. Gtk.jl
is still evolving, but it's clearly headed in a great direction.

I would choose the native Gtk.jl over a python/Qt intermediary without
question---I did some performance profiling a few months back, and going
through python was not pretty. I'm talking about factors of 10-100 here, and
as a "big data" guy who wants to plot large numbers of points, in my book that
performance gap utterly rules out python as a long-term foundation for
graphics in Julia.

With regards to whether Tobi is taking a big risk developing the IDE in
Gtk.jl: my experience in porting ImageView from Tk.jl to Gtk.jl was that doing
the ImageView port was only about 10% of the work (i.e., not too bad), 90% was
improving Gtk.jl itself. In other words, even if a Qt.jl package eventually
appears, switching Julietta over to it would be vastly less effort than
developing Qt.jl in the first place.

I think it's possible to be of two minds: if you search old archives you'll
see I had my own reservations about choosing Gtk+ rather than sucking it up
and wrapping Qt. But having dived into Gtk, I'd say it's pretty darn good (at
least on Linux, I haven't tested on other platforms). Besides, I'm coming from
a Matlab background, and what you can do with Gtk.jl/Cairo.jl is such a huge
step up it's not even funny :). Compared to a gap like that, and the practical
realities of wrapping a big C++ library, the differences between Gtk+ and Qt
hardly seem worth worrying about.

Best,
--Tim

[Tobi]

Great summary Tim.

I want to second that the API of Gtk and also Cairo are pretty well designed. In C its lots of typing but properly wrapped
in Julia, the code is actually pretty neat.

I have also thought about whether it is feasible to make the GUI toolkit more abstract so that one might switch between backends.
In practice this gets complicated when getting into details.

And while the Qt/Gtk discussion is a classical one, what will be much more interesting in the future is how we can wrap Android and iOS
APIs...

[Gour]

On Fri, 7 Feb 2014 03:01:46 -0800 (PST)
Tobi <tobias...@googlemail.com> wrote:

> And while the Qt/Gtk discussion is a classical one, what will be much
> more interesting in the future is how we can wrap Android and iOS
> APIs...

http://blog.qt.digia.com/blog/2014/02/05/qt-5-2-1-released/ :-)


Sincerely,
Gour

--
One who is not disturbed in mind even amidst the threefold
miseries or elated when there is happiness, and who is free
from attachment, fear and anger, is called a sage of steady mind.

[Björn Linse]

An alternative for wrapping QT might be to use smoke ( http://techbase.kde.org/Development/Languages/Smoke ) which seem analogous to gobject-introspection for Gtk and is used to implement several scripting bindings (i e Qt for Ruby). While the Smoke API itself is c++, it's possible that the exposed methods/signals are usable using mostly C ABI. I started working on gobject-introspection since a pure C API seemed simpler and GLib/Gtk.jl was already far progressed, but it might be possible to reuse the ideas also for qt-smoke bindings.

[Milan Bouchet-Valat]

Le vendredi 07 février 2014 à 10:48 +0100, Gour a écrit :
> > I am aware of that and the main issue seems to be that Gtk has not
> > enough contributors.
>
> And those seems to be hostile to scare people away.
>
> > If Julia with Gtk.jl gets some momentum, we might also improve Gtk+
> > cross-platform capabilities upstream.
>
> We know who controls GTK, so I'll not hold my breath.

Asserting that Red Hat (I guess it's the one you refer to) acts against
efforts to port GTK to Windows and OS X is just bullshit. GTK is clearly
oriented primarily towards GNOME/Linux as most developers are using it
on this platform, but everybody agrees other platforms are important.

Recently there's been much progress to get GTK3 work better on Windows,
and even build with MSVC. On the download page you can get binary and
source bundles with everything you need for Windows.

Finally, in my experience GIMP looks OK on all three platforms. Just
have a look at their screenshots: http://www.gimp.org/screenshots/

> > This is all better than wrapping a C++ library :-)
>
> Well, C++ wrapping is not easy, but it's long-term gain.
>
> > > There are also lots of projects moving away from GTK.
> > >
> >
> > I know one that is moving towards it :-)
>
> I should say 'migrating'. Even DEs like LXDE are moving to Qt.

You use a plural. Do you have other examples of DEs switching to Qt?
None, that's just rhetoric.


Your help is welcome to create Qt bindings for Julia, or to improve
Julia studio (which uses Qt). But ranting against GTK is not exactly
useful.

[Eric Davies]

If anyone is interested in wrapping wxc, it is part of the wxHaskell repo here: https://github.com/wxHaskell/wxHaskell/tree/master/wxc/src

It's essentially a bunch of .cpp files containing mostly extern "c" {...} declarations. I'm guessing this would be an easy case for Cpp.jl.

[Steven G. Johnson]

On Friday, February 7, 2014 2:58:58 AM UTC-5, Gour wrote: 

As far as Julia is concerned, it probably does not compete with C++,
but more with Python and here Python rules having GUI bindings for
practically everything, so my point is if it's possible for Python, why
not Julia (accepting the fact it's not easy) ?

Oh, it is certainly technically possible to call C++ libraries such as Qt from Julia, just like in Python.  The most straightforward way is to write a thin C glue layer.  In Python that is typically done automatically using SWIG (or Shiboken in the case of PySide).   It's just annoying in Julia because we'd prefer not to have to write any C glue at all.

[Björn Linse]

A possibility for wrapping Qt might be to use qt-smoke (http://techbase.kde.org/Development/Languages/Smoke). It seem analogous to gobject-introspection, which wraps very well in julia. (not used by Gtk.jl yet, but this is in progress) While smoke itself is a c++ api, it looks at the first examples that method invocation can be done with only C ABI. It is still a level of indirection, but should be a lot cheaper than using pyside, for instance. 

[Jameson Nash]

> That's true, but GTK looks ugly on everything non-Linux and the devs are
not very enthusiastic to support practically anything non-GNOME.

> What about wx? It uses native widgets and looks much better.

I spent a while (1 year+?) before starting to seriously work on Gtk.
Why? Because I use a Mac and it doesn't look very pretty OOTB (IMO,
Gtk looks better on Windows than many Windows apps). However, Tk is
terrible in every way, so I didn't want to allow it to become the
defacto toolkit like happened to Python.

Yes, wx also looked nice. wxc even seemed to provide reasonable C
bindings. However, I was nervous about the time that had elapsed since
their last update (no longer true, but I'm quite happy with Gtk after
spending a while to understand it while wrapping it).

Qt is also probably great, but it's C++, so it's much, much harder to
write good, flexible wrappers.

However, that's only if you insist of wrapping cross-platform
toolkits. Assuming you are on a Mac (since you seem to care about UI),
it would be nice if someone wrote a wrapper for the native platform
API, since ObjC can be directly ccall'd without any annoying magic
like C++. Then we would have native wrappers for two platforms (Gnome
and Mac).

[Tobi]

Here is a screenshot of Julietta on OSX using the Adwaita theme:

Does this really look so ugly? Changing the theme is described here http://blog.e-shell.org/60

You bring up a very good point about Python and Tk. We need to get to a point where someone can download Julia and write GUIs right away in a modern toolkit. IMHO Julia has a very great potential for writing GUIs and I don't want that Julia ends up being neat for console apps but not so neat for GUIs.

I want to second it would be very helpful to get the native OSX toolkit wrapped. Cross-platform is always a compromise and people that care will always write the frontend in the native toolkit (e.g. look at the Github GUIs)

Having multiple native toolkits would further enable us to write a cross-platform toolkit on top of that.

[Tobi]

To get back on topic:

- Is there a "readir" like function that doesn't give me hidden folders? I know, on OSX and Linux I can remove the dot but on Windows this is a file attribute.

- Is there a function that tries to parse Julia source code and tell me if it is valid and if not, at which line the error occurred? I could use Base.parse_input_line but in the returned AST the line is not always encoded. I have further no experience in traveling through the AST. Are there any good examples?

[Jameson Nash]

That's a great tool to know about. Perhaps you could make a pull
request against Gtk.jl adding a THEMING.md file describing how to make
it look better on different platforms.

not that I'm aware of. On Mac/BSD, its in the st_flags part of calling
Stat(). But on Linux/Windows, that field is 0.

parse(str, pos, raise=false)

[Gour]

On Fri, 07 Feb 2014 04:40:40 -0600
Tim Holy <tim....@gmail.com> wrote:

Hi Tim,

> Gour, if you'd like to start a Qt.jl package, that would be great. If
> you succeeded in overcoming the major hurdles, I suspect there would
> be considerable interest. (The reason I started Cpp.jl was in part
> aiming towards Qt.)

I'm glad there are people here considering that Qt bindings might be
good thing for Julia.

Let me say tyhat yesterday evening I spent some time reading Julia's
docs on my small 7" tablet and I must say I'm *very* impressed with the
Julia as a language. It looks there is finally elegant language allowing
to use FP paradigm (amongst others), no need to take care about pointers
& other low(er)-level stuff, clean syntax, lots of library support, easy
C calling (FFI), great performance...

In short: Julia seems to be 'fine general programming language'. :-)

Based on everything above, I strongly believe that Qt bindings would be
killer feature!!

> Given that Python has wrapped Qt, I agree it's surely possible for
> Julia as well. But keep in mind that Python has been around a long
> time, has gone through several iterations of Qt wrappers, and
> collectively those wrappers have had probably tens-of-thousands of
> human-hours thrown at them (including corporate-sponsored hours).

I'm aware of that, but let's try to focus on 'is possible'. PyQt is nice
example of having decent high(er)-level bindings for C++ toolkit.

> In contrast, Gtk.jl is basically the work of 4 people (of whom Jameson
> is by far the most significant), and it's extraordinary how _pretty_
> the guts of it are and how productive that effort has been. Gtk.jl is
> still evolving, but it's clearly headed in a great direction.

Well, the GTK+ team itself is not very crowded place as well.

> I would choose the native Gtk.jl over a python/Qt intermediary
> without question---I did some performance profiling a few months
> back, and going through python was not pretty. I'm talking about
> factors of 10-100 here, and as a "big data" guy who wants to plot
> large numbers of points, in my book that performance gap utterly
> rules out python as a long-term foundation for graphics in Julia.

Do you mean PyCall.jl or straight PyQt/Python?

Iirc, I stumbled upon some benchmarks recently where Julia was compared
with Python/Cython and the difference was no so great, but not sure
about the details?

I'm also looking for a decent language for 'general desktop' application
involving some number crunching (e.g. we need to use 3rd party C library
for calculating planetary ephmeris), but we need good GUI on top of
that.

> With regards to whether Tobi is taking a big risk developing the IDE
> in Gtk.jl: my experience in porting ImageView from Tk.jl to Gtk.jl
> was that doing the ImageView port was only about 10% of the work
> (i.e., not too bad), 90% was improving Gtk.jl itself. In other words,
> even if a Qt.jl package eventually appears, switching Julietta over
> to it would be vastly less effort than developing Qt.jl in the first
> place.

In regard to Tobi's work, intention of my question was not solely
Julietta itself, but Qt bindings in general and e.g. why not PyCall with
Qt?

My interest is not so much in which GUI is IDE for the language written
'cause I believe that vim can serve me for quite some time on the way
while working on the app.

> I think it's possible to be of two minds: if you search old archives
> you'll see I had my own reservations about choosing Gtk+ rather than
> sucking it up and wrapping Qt. But having dived into Gtk, I'd say
> it's pretty darn good (at least on Linux, I haven't tested on other
> platforms).

I'm using Linux since '99 and only for short time I was using KDE -
sometime in the 0.9 era iirc. The rest of the time it was either GNOME2
or mostly XFCE and now, since some time I use plain i3.

So I always liked/preferred GTK, but trying to be pragmatical, I do not
believe there is much future for GTK except on Linux/GNOME.

Qt is simply superior in so many aspects today, starting with the docs,
number of devs/community, OS support etc.

However, as someone who *might* be just interested to *use* Julia and
its ecosystem, but probably without time to work (I can afford to only
work on my hobby open-source project in my free time) on the project of
the Qt.jl-size, I will stop here.


Sincerely,
Gour

--
The working senses are superior to dull matter; mind is higher
than the senses; intelligence is still higher than the mind;
and he [the soul] is even higher than the intelligence.

[Tim Holy]

On Saturday, February 08, 2014 10:58:58 AM Gour wrote:
> Do you mean PyCall.jl or straight PyQt/Python?

I was experimenting with the plotting demos at
https://github.com/jverzani/PySide.jl. It's a very nice package, though.

--Tim

[Tobi]

Yes this needs docu. But I think we will also want a simple installer for Gtk that automatically choses a sane theme.

will make a PR to base for a cross-platform function "ishidden(filename::String)". I assume that there are winapi calls for this.

Will have a look at parse, thanks

[Pierre-Yves Gérardy]

On Saturday, February 8, 2014 7:29:05 AM UTC+1, Tobi wrote:

Does this really look so ugly? Changing the theme is described here http://blog.e-shell.org/60

Some people feel strongly about this. I don't, but while I don't think it looks bad, I can't say it looks good either.

It's mostly weird.

There is no sub-pixel antialiasing, and the lower case 'g's are truncated.

The [Sans|13] button doesn't look bad, but I'm not sure I've ever seen a vertical division in a button.

The cross to close the tabs is way too big, and the check boxes are off.

OS X has actually "drop arounds" rather than drop down menus. On click, the list is centered around the selected option.

Toolbars are usually more compact (less vertical blank space), and only use one line. I think you could get rid of it in its current shape. Standard menus, keyboard shortcuts and a preference window are better suited for these tasks IMO.

The scroll bars, since at least 10.8 (not sure about 10.7, I skipped it), are hidden and only appear as translucent overlays when scrolling (a loss in usability, IMO, but it's how it's done).

Proper antialiasing, no toolbar, and smaller crosses to close the tabs would already go a long way.

Keep it up :-)

—Pierre-Yves

[Tobi]

Hi Pierre-Yves,

I don't get your post as a rant but we have definitely reached a level of details that was not my intention with my post. I posted this on purpose on julia-devel to get feedback on the architecture and functionality of my work. On not so much about the design.

The screenshot I made was with the Adwaita theme that of course does not look as a OSX theme as it is/was(?) the default gnome theme. There are on gnome-looks themes that make Gtk look very very similar to OSX.

There are various sizes in the applications that are currently not optimized and can be easily fixed.

The toolbar will definitely be cleaned up. I currently put everything in there to test functionality. But in general I will not get rid of the toolbar. It is absolutely common to use toolbars and actually I see people going away from menus. E.g. on windows (and matlab) you have very large toolbars called Ribbons.

Would be great if someone could actually test if Julietta is working for them. I have, for instance, not yet tested Julietta on Linux.

I am currently not really happy with my terminal implementation. It uses an entry where only single line commands can be entered and the output is pasted into a text view. The nice thing about it is that one gets automatic autocompletion suggestions in form of a drop down list (like in googles search box) I think this is very neat.

[Gour]

On Thu, 6 Feb 2014 11:50:35 -0800 (PST)
Tobi <tobias...@googlemail.com> wrote:

Hello Tobi,

> More seriously: I started with this to explore whether Julia is a
> good fit for GUI programming. I have quite some experience with
> WPF/C# and have to say that Gtk.jl is seriously getting an absolute
> awesome package. Various things are in flux and missing but what is
> there is really cool.

In my ongoing evaluation of Julia vs Dylan where availability of GUI
bindings is important concern, I wonder if Gtk.jl does support using
Glade-created layouts?

I see that there is https://github.com/JuliaLang/Gtk.jl/blob/master/src/builder.jl
but not familiar enough with GTK to discern?


Sincerely,
Gour

--
The spirit soul bewildered by the influence of false ego thinks
himself the doer of activities that are in actuality carried out
by the three modes of material nature.

[Tobi]

Yes. I added these and they work quite well with glade.

[Gour]

On Sun, 2 Mar 2014 01:01:01 -0800 (PST)
Tobi <tobias...@googlemail.com> wrote:

> Yes. I added these and they work quite well with glade.

Thanks. Good news. ;)

Sincerely,
Gour

--
The working senses are superior to dull matter; mind is higher
than the senses; intelligence is still higher than the mind;
and he [the soul] is even higher than the intelligence.