Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
Bertrand Meyer
The Mac issue is indeed serious; as Thomas writes, the platform is growing in importance and it is a shame that EiffelStudio does not install “straight out of the box”.
The issue come not from EiffelStudio itself but from GTK. So there are two possible strategies:
1. Build a professional-quality GTK installation procedure for the Mac (even though it’s not an Eiffel-community product, it is critical for EiffelStudio as currently set up).
2. Build a native Macintosh EiffelVision handle (i.e. offer a true Mac look-and-feel rather than a Unixy GUI).
Either way it would be great to do this as a community effort since Eiffel Software is more effective focusing its work on the core technology. We would support the effort extensively of course.
Solution 1 can be criticized as a kludge but it would remove the eyesore (or the thorn in our side, whichever anatomical part you prefer for the metaphor).
Solution 2 has been debated many times in the past and there have been a number of efforts, in particular one at ETH which got “almost there” and should clearly serve as the starting point.
We are interested in knowing whether anyone is seriously interested in participating in such an effort or better yet leading it. If you are, you can write to me directly and I will share with others involved.
-- Bertrand Meyer
From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Thomas Beale
Sent: Friday, 03 March, 2017 15:55
To: Eiffel Users <eiffel...@googlegroups.com>
Cc: kwa...@mail.ru
Subject: Re: [eiffel-users] Binary Mac download for EiffelStudio?
Alexander,
thanks, but it didn't help. This is the message I got back from my colleague:
> Hi Thomas,
>
> I had tried these steps as well but they all failed and gave very little information as to why. I give up. Sublime will have to do. Getting pretty good at navigating sublime Eiffel code :) Too bad they simply don't just develop a dmg file or a package file for MacOS.
He's a very experienced developer, not a newbie, It's not a great situation given that the majority of devs I see these days use Macs.
- thomas
On Thursday, March 2, 2017 at 6:26:34 PM UTC, Alexander Kogtenkov wrote:
There is some progress simplifying installation of EiffelStudio on Mac, but for the time being I'd suggest two links that explain what to do:
1. Recommended instructions: https://www.eiffel.org/doc/eiffelstudio/Mac%20OS%20X
2. Advanced instructions with more options: https://dev.eiffel.com/EiffelOnMac
And there is binary installation for Mac (e.g., it can be downloaded from https://sourceforge.net/projects/eiffelstudio/files/), but it is not automatic and is described in item 2 above.
Hope this helps,
Alexander KogtenkovThomas Beale <wolan...@gmail.com>:
I pointed a colleague to the usual place (eiffel.org/downloads) to obtain a Mac version of EiffelStudio. I had thought all the installers there were binary, like the Windows one. He tells me the Mac one has to be built form source on his machine, and that it doesn't work. Is this how Mac users of EiffelStudio usually have to install Eiffel?
- thomas
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Woland's Cat
Let me just say that this problem, if we make an effort to solve it, _must_ be solved for non-tech people, because most applications that are developed are for such people. Our application, the Archetype workbench, is mostly used by clinical people and people who work in health informatics. Only a minority even understand what 'MacPorts' or 'Homebrew' actually are, and when they get presented with some difficult procedure, they balk. If they don't, they see that MacPorts installs many Gb of software on their machine, which they don't like.
Whatever the solution is, it has to have as a result that we Eiffel users can easily create a package for the app we want to distribute, and that package itself installs in a standalone way, without any other unexpected difficulties. I am less worried about whether the UI is native Mac or GTK.
- thomas
On 09/03/2017 17:10, Bertrand Meyer wrote:
Emmanuel Stapf
MacPorts, we have to find an install package for GTK that works with
Vision2. Then we can install EiffelStudio via an installation
procedure as we used to do it back when GTK 1.2 was available this
way. If not possible, Vision2 has to be adapted to work without GTK so
that one can build an installer.
Manu
> You received this message because you are subscribed to the Google Groups
> "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to eiffel-users...@googlegroups.com.
> Visit this group at https://groups.google.com/group/eiffel-users.
> For more options, visit https://groups.google.com/d/optout.
------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------
Bernd Schoeller
As a third suggestion, we might think about wrapping Qt.
Qt offers a native user experience and is available on all major platforms supported by EiffelStudio. So, if we manage to switch to Qt, we might even get away from EiffelVision2 and directly use Qt on all platforms (though that would be a larger endeavor).
This being said, I have not yet done any wrapping of that library
and it might be more difficult because Qt uses some very unusual
abstractions (like the 'signal-slot' mechanism and the MOC
precompiler).
Bernd
Finnian Reilly
I have developed extensively with Vision2 (+ docking library) and created many extensions for it, and I have to agree with the spirit of Bernard's suggestion: we should be looking to get away from Vision2. Vision2 is nice to work with if you are only developing for one platform and don't need anything too fancy. But creating a sophisticated application like My Ching that works consistently on all platforms is far from simple and very time consuming. There are too many gotchas that require a careful balancing act, not unlike walking on a tight-rope. Also I found I spent too much time developing extensions to fill in deficiencies. To give a few of examples
1. These was no scrollable area that was both expandable and
center-able and responsive to standard keyboard shortcuts in a
consistent manner between platforms.
2. There was no text component that had standard undo-redo functionality.
3. There was no hyper-link component
These are just three examples but I can give many more. If I was working with a truly mature GUI library I could probably have developed My Ching in 1/3 of the time or less.
I am not convinced that we have a sufficient base of Eiffel community
developers to make Vision2 work well on 2 desktop platforms let alone
3. If I am going to volunteer my time to a new GUI project I would feel
much more motivated and enthusiastic to work on a binding for a mature
library that already has a size-able community supporting it. In fact I
have already been thinking of doing a pilot project.
WxWidgets V QT
Where I disagree with Bernard is, I would much prefer to create a
binding for WxWidgets rather than QT. WxWidgets has all of the
advantages of QT and none of the disadvantages, namely it does not
require any special C++ extensions and does not require a license for
commercial development.
Here is a list of reasons which make WxWidgets attractive:
- It is a mature library that has been going for 25+ years
- It is well supported with 113 contributers and is being actively maintained. The last major release was Feb 2016. The fact that it is well supported is probably due to the many language bindings it has, so it has a large user base.
- It has an impressive portfolio of apps that use it: https://www.wxwidgets.org/about/screenshots/
- It has platform support for Unix, Windows and OSX and gives applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI.
- There is 700 page book written about it.
Peter Gummer
Where I disagree with Bernard is, I would much prefer to create a binding for WxWidgets rather than QT. WxWidgets has all of the advantages of QT and none of the disadvantages, namely it does not require any special C++ extensions and does not require a license for commercial development.
Gerrit Leder
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Peter Gummer
Hi Peter,sorry, but your link is Broken. It redirects to
Finnian Reilly
But back to WxWidgets. Thanks Peter for mentioning about the wxEiffel. I wasn't aware of it's existence.
As Gerrit pointed out the link was broken but I found the home page for wxEiffel: http://elj.sourceforge.net/docs/wxEiffel/ And the source code can be found here: https://sourceforge.net/projects/elj/
First thing to note is this project binds to WxWindows, which was the precursor to the cross-platform library WxWidgets, and also to a time when ISE (now ISO) Eiffel and SmartEiffel were vaguely compatible. I believe at at some point an alternative event binding system was introduced in WxWidgets making it easier to bind to external languages. It might be better to start again from scratch, but still the existing wxEiffel code could be worth studying to see if anything is salvageable and we might learn something too.
A propos, I was looking at some of the controls WxWidgets has to offer. Take a look at this screenshot for the wxRichTextCtrl. Impressive, no! Of course Vision2 has a rich text control too but I don't think it is as advanced. You can't embed images for example.
Also have a look at this Python tutorial for wxHTML. This is not the same as an embedded browser which WxWidgets also has. I wrote a very rudimentary one for Vision2 but nowhere near as good as this one. Mine can't do tables.
On Sunday, 12 March 2017 09:19:59 UTC, gerrit.leder wrote:
Hi Peter,sorry, but your link is Broken. It redirects toI have never developed w/ GUI frameworks except AWT/swing/SWT for Java. But I like the idea of QT or wxwidgets as a vision2 replacement.Pro:- great abstraction of signals and slots for QT- portability- GUI BUILDERS existCon:- doubtful if GUI builders have to be ported for eiffel- precompiler for QTBRGerrit
Am 12.03.2017 01:11 schrieb "Peter Gummer" <p-gu...@bigpond.net.au>:
On 12 Mar 2017, at 00:48, Finnian Reilly <frei...@gmail.com> wrote:Where I disagree with Bernard is, I would much prefer to create a binding for WxWidgets rather than QT. WxWidgets has all of the advantages of QT and none of the disadvantages, namely it does not require any special C++ extensions and does not require a license for commercial development.
Hi Finnian,I think you mean Bernd, not Bernard ;-)There is an Eiffel binding for WxWidgets at http://elj.sourceforge.net/projects/gui/ewxw/, but it’s 15 years old. It may be useful as a starting point.- Peter Gummer
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Joe Abbate
> On 12 Mar 2017, at 20:19, Gerrit Leder <gerrit...@gmail.com
>>
>> Hi Peter,
>>
>> sorry, but your link is Broken. It redirects to
>> https://www.wxwidgets.org/docs/faq/general/
>
>
> It works for me. There are some annoying pop-up windows, but if you
> dismiss them then the page is there.
Joe
Finnian Reilly
https://archive.eiffel.com/general/editorial/1998/combinator.html
The need for a combinator
It looks like the idea of component-based software development has finally captured the industry's attention. This is great news for people who have long been promoting software reusability and object technology; for the first time, reuse has a real chance of succeeding on a broad scale. A chance, not a certainty.
If there is any certainty, it's that no single standard will suffice to develop and distribute reusable components. This is partly a matter of circumstances (each of the big players has high stakes in seeing *its* standard succeed) and partly a matter of technical requirements. Some of the formalisms that may play a substantial role are C, C++, Eiffel, Java, CORBA's Interface Definition Language (IDL), CORBA IIOP, Microsoft's OLE/COM and DCOM, Visual Basic, JavaBeans, HTML and other Web mechanisms.
After years of component drought, shall we have component flood? If so, the risk exists that all those components will be incompatible with each other. Here Eiffel can play a useful role as *component combinator*, enabling various pieces of software, built with various technologies, to lie together as peacefully now as the lion and the lamb will at the end of time.
[...] The role of Eiffel here is less that of an implementation language (except for the components implemented in Eiffel) than of a connecting tool -- the glue between the components.
Bertrand Meyer
Thanks for bringing this up. Of course the vision is as relevant today as it was then.
The weakness of Eiffel here is that the combination mechanisms are not very dynamic. At least that’s a perceived weakness (personally I am sensitive to the benefits of doing some of the combination statically – you know what you are delivering and can verify it!).
The strength of Eiffel, on the other hand, lies in the flexibility and generality of the modular mechanisms and in the Design by Contract mechanism. To combine components effectively you need to know what they are about: what they guarantee to others, expect from others, and keep invariant. These points were made in a number of articles and remain applicable.
-- BM
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Finnian Reilly
On Sunday, 12 March 2017 16:32:16 UTC, Bertrand Meyer wrote:
The weakness of Eiffel here is that the combination mechanisms are not very dynamic. At least that’s a perceived weakness
-- Finnian
Rosivaldo Fernandes Alves
recombination of binary, already compiled components, which was a
pursuit in the nineties. Eiffel was seen as a language not very tailored
for this kind of component re-usability.
Em 12/03/2017 16:05, Finnian Reilly escreveu:
>
> On Sunday, 12 March 2017 16:32:16 UTC, Bertrand Meyer wrote:
>
>
>
> The weakness of Eiffel here is that the combination mechanisms are
> not very dynamic. At least that’s a perceived weakness
>
>
> If I understand correctly, you are saying static typing is perceived as
Louis M
Good day,
Louis Marchand
Woland's Cat
That's also what I thought Bertrand was referring to. A modern versions of this is the JVM / jar ecosystem.
On 12/03/2017 16:13, Rosivaldo Fernandes Alves wrote:
Prof. Meyer may correct me, but I think his point has to do with recombination of binary, already compiled components, which was a pursuit in the nineties. Eiffel was seen as a language not very tailored for this kind of component re-usability.
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog | Culture blog
Bertrand Meyer
Thanks to the several people who have responded enthusiastically and volunteered to participate. I continue writing to this list rather than a smaller circle because we are still at the stage of a general discussion in which a broad community discussion is essential..
Here is the state of our (Eiffel Software’s) thinking on the matter.
1. As noted before, the issue with the Mac version is not specifically a Mac implementation problem but a problem with the user interface, and specifically with the installation of GTK, which is beyond our control (although of course one could envision working on GTK installation itself).
2. Other than GTK, there is the possibility of working on an EiffelVision “handle” (i.e. a specific bridge) to Cocoa -- already the target of considerable effort, but not complete -- or, as has been suggested here, Qt.
3. We think, however, that this is not the best approach. 10 or 15 years ago, offering a native look-and-feel on each platform was critical. Nowadays, many people don’t care about the UI exactly conforming to the platform’s standard as long as it looks good -- including if it looks like a modern Web-style interface.
The most attractive approach, then, seems to be to turn EiffelVision 2 into EiffelVision 3, which would retain a backward-compatible API but would shed the dependency on platform-specific toolkits: the Windows graphics API, GTK, Cocoa. To this effect, EiffelVision 3 draws everything itself, in the most efficient and graphically pleasing way possible. Of course it has to retain some platform-specific elements (handles), but limited to the strict minimum -- basic drawing.
We estimate that the work on individual widgets is about two weeks for one person (on average, although some widgets will be harder than others). That work could be divided into a number of people, with a project coordinator.
In the short term the existing handles (Windows, GTK) would be kept for compatibility.
Comments?
With best regards,
-- Bertrand Meyer
Joe Abbate
> The most attractive approach, then, seems to be to turn EiffelVision 2
> into EiffelVision 3, which would retain a backward-compatible API but
> would shed the dependency on platform-specific toolkits: the Windows
> graphics API, GTK, Cocoa. To this effect, EiffelVision 3 draws
> everything itself, in the most efficient and graphically pleasing way
> possible. Of course it has to retain some platform-specific elements
> (handles), but limited to the strict minimum -- basic drawing.
toolkits go against the principle of code re-use?
BTW, I think Finnian had also suggested wxWidgets as an alternative.
Cheers,
Joe
Ian Joyner
Mischa Megens
https://imgs.xkcd.com/comics/standards.png
Best,
Mischa
On 4/3/2017 6:06 PM, Bertrand Meyer wrote:
Louis M
Le lundi 3 avril 2017 12:06:17 UTC-4, Bertrand Meyer a écrit :
The most attractive approach, then, seems to be to turn EiffelVision 2 into EiffelVision 3, which would retain a backward-compatible API but would shed the dependency on platform-specific toolkits: the Windows graphics API, GTK, Cocoa. To this effect, EiffelVision 3 draws everything itself, in the most efficient and graphically pleasing way possible. Of course it has to retain some platform-specific elements (handles), but limited to the strict minimum -- basic drawing.
I think that what we are talking here is about reinventing the wheel. I do not think that this is a good approach. Particularly for a language that promote reusability.
In a more practical view, the fact that we redraw the widgets remove the possibility of users to used system accessibility features (screen reader, high contrast, etc.). Also, using this remove the possibility of using Regression test tool like LDTP.
Louis M
Bertrand Meyer
You have a point but I think we should avoid engaging in a discussion of principle about reuse**. The matter is pragmatic: are we better off with a technology we control, or with dependence on someone else’s technology?
The current situation is precisely that we relied on reuse -- of GTK; but then GTK has problems on the Mac and it is EiffelStudio that gets a bad rap as a result. If EiffelStudio has installation problems on the Mac it does not help much to argue that it is GTK’s fault (as a rule people are not interested in excuses but in results!).
One is always reinventing some part of the wheel -- the question is not whether, but how much. In the line of thinking that I described, the dependence on toolkits -- which was without any doubt the right way to go a decade or two ago -- seems, in 2017, to bring more trouble than advantages. Redoing the widgets ourselves seems like a tractable effort, and would enable us to guarantee the level of quality that Eiffel users expect, since we would be in charge of a larger part of the chain (or the wheel, to avoid mixing metaphors).
So it is not really a philosophical question about reuse but a matter of degree. If we had a reusable toolkit that covers all platforms and that we could trust, it would be the clear solution, but we do not see one right now.
All this subject to further discussion.
Thanks and best regards,
-- Bertrand Meyer
**For the record, I have always been an enthusiastic supporter of software reuse, starting long before the concept was popular, but I have always included the appropriate caveats alongside the arguments in favor, as in this extract from my 1995 book “Object Success” (Prentice Hall), an object technology guide for managers: “If others are responsible for the product, they are also responsible for corrections and adaptations. In an industry which is often devoting 50% to 80% of its resources to maintenance, this is a precious benefit; reuse can enable you to devote your efforts to new applications, not to the backlog of maintaining existing applications. There is of course another, less enticing side: since you are not fully in control of the software, you depend on someone else to update it when needed.” The scenario mentioned (emphasis added) is exactly what we have been facing with GTK.
From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Louis M
Sent: 04 April 2017 15:20
To: Eiffel Users <eiffel...@googlegroups.com>
--
Davide Grandi
What about an Eclipse-like approach ?
A sort-of "facade" pattern, I mean, with a specific component
for every platform.
Best regards,
Davide Grandi
-- Ing. Davide Grandi email : davide...@mclink.it mobile : +39 339 7468 778
Bertrand Meyer
This is pretty much what we have now. There is a “handle” for every platform. (Sort of a bridge pattern, but used and in fact published before the term “bridge” was devised.)
-- BM
--
Joe Abbate
> You have a point but I think we should avoid engaging in a discussion of
> principle about reuse**. The matter is pragmatic: are we better off with
> a technology we control, or with dependence on someone else’s technology?
>
> The current situation is precisely that we relied on reuse -- of GTK;
> but then GTK has problems on the Mac and it is EiffelStudio that gets a
> bad rap as a result. If EiffelStudio has installation problems on the
> Mac it does not help much to argue that it is GTK’s fault (as a rule
> people are not interested in excuses but in results!).
choosing GTK on the Mac, but if I'm not mistaken, in GUIland, aren't you
always dependent on someone else's technology?
I mean, for example on Windows, you'll write to the Windows API, right?
So the question becomes what to do on macOS and Linux/Unix variants. On
top of what (Cocoa, Carbon, X11, Wayland, GTK+, Qt) is EV3 proposed to
be built?
Joe
Seref Arikan
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Bertrand Meyer
-- BM
-----Original Message-----
From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Joe Abbate
Sent: 04 April 2017 18:27
To: eiffel...@googlegroups.com
Subject: Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
Woland's Cat
Another aspect to remember is that while the EiffelVision concept is good, it doesn't go nearly far enough in providing an efficient UI library - i.e. the top API. Myself and others here have slowly built up various higher-level complex controls over the years to make EV2 programming tolerably efficient, e.g. tree widget + tree expand/collapse control set; directory chooser widget and many more. All of this is primitive by today's standards of JavaScript-based UI languages & toolkits. These languages have a pretty reasonable functional / lambda based approach, and I suspect they achieve a lot of what EV2 set out to do with agents in an acceptable way.
Given that the Eiffel world has limited resources I would probably be trying to find a way to provide high-quality UI building either in one of the JavaScript toolkits and connect that to Eiffel back-ends, or else consider how to recreate such an environment natively in Eiffel.
So - maybe the EiffelVision2 API isn't the reference point?
- thomas
Jonathan Wilcox
I have not programmed in 10 years, but EiffelVision 3 is a project that would get me back into it.
Jonathan Wilcox
Seref Arikan
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog | Culture blog
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.
karsten.heusser
There are GUI libraries on top of OpenGL:
https://github.com/libglui/glui/wiki
https://code.google.com/archive/p/begui
Furthermore, the Khronos Group seems to be sufficiently stable
to rely on in the long term: https://www.khronos.org
Unfortunately, Khronos does not offer something like OpenGUI
and GLUI and beGUI are more or less meant for OpenGL programmers.
Maybe, OpenGL could be an option to get rid of platform dependency.
Best,
Karsten
Volkan Arslan
The major web browsers such as Chrome, Firefox, Edge already support WebAssembly although currently only in experimental mode.
Von: "Woland's Cat" <wolan...@gmail.com>
An: eiffel...@googlegroups.com
Betreff: Re: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
Bertrand Meyer
The discussion started by the message below has converged on the project of a Web Assembly implementation. There is a first meeting (using WebEx) next Thursday:
Thursday, 7 September 2017
15:30 Paris/Milan/Brussels time, i.e. 14:30 UK,9:30 US EDT, 23:30 Sydney etc.
If you have not been involved in the discussion so far but would like to join that discussion please send me an email and I will give you the WebEx link.
With best regards,
-- Bertrand Meyer
From: Bertrand Meyer [mailto:Bertran...@inf.ethz.ch]
Sent: Thursday, March 9, 2017 21:10
To: eiffel...@googlegroups.com
Cc: kwa...@mail.ru; me...@inf.ethz.ch
Subject: Macintosh version -- RE: [eiffel-users] Binary Mac download for EiffelStudio?
The Mac issue is indeed serious; as Thomas writes, the platform is growing in importance and it is a shame that EiffelStudio does not install “straight out of the box”.
The issue come not from EiffelStudio itself but from GTK. So there are two possible strategies:
1. Build a professional-quality GTK installation procedure for the Mac (even though it’s not an Eiffel-community product, it is critical for EiffelStudio as currently set up).
2. Build a native Macintosh EiffelVision handle (i.e. offer a true Mac look-and-feel rather than a Unixy GUI).
Either way it would be great to do this as a community effort since Eiffel Software is more effective focusing its work on the core technology. We would support the effort extensively of course.
Solution 1 can be criticized as a kludge but it would remove the eyesore (or the thorn in our side, whichever anatomical part you prefer for the metaphor).
Solution 2 has been debated many times in the past and there have been a number of efforts, in particular one at ETH which got “almost there” and should clearly serve as the starting point.
We are interested in knowing whether anyone is seriously interested in participating in such an effort or better yet leading it. If you are, you can write to me directly and I will share with others involved.
-- Bertrand Meyer
From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Thomas Beale
Sent: Friday, 03 March, 2017 15:55
To: Eiffel Users <eiffel...@googlegroups.com>
Cc: kwa...@mail.ru
Subject: Re: [eiffel-users] Binary Mac download for EiffelStudio?
Alexander,
thanks, but it didn't help. This is the message I got back from my colleague:
> Hi Thomas,
>
> I had tried these steps as well but they all failed and gave very little information as to why. I give up. Sublime will have to do. Getting pretty good at navigating sublime Eiffel code :) Too bad they simply don't just develop a dmg file or a package file for MacOS.
He's a very experienced developer, not a newbie, It's not a great situation given that the majority of devs I see these days use Macs.
- thomas
On Thursday, March 2, 2017 at 6:26:34 PM UTC, Alexander Kogtenkov wrote:
There is some progress simplifying installation of EiffelStudio on Mac, but for the time being I'd suggest two links that explain what to do:
1. Recommended instructions: https://www.eiffel.org/doc/eiffelstudio/Mac%20OS%20X
2. Advanced instructions with more options: https://dev.eiffel.com/EiffelOnMac
And there is binary installation for Mac (e.g., it can be downloaded from https://sourceforge.net/projects/eiffelstudio/files/), but it is not automatic and is described in item 2 above.
Hope this helps,
Alexander KogtenkovThomas Beale <wolan...@gmail.com>:
I pointed a colleague to the usual place (eiffel.org/downloads) to obtain a Mac version of EiffelStudio. I had thought all the installers there were binary, like the Windows one. He tells me the Mac one has to be built form source on his machine, and that it doesn't work. Is this how Mac users of EiffelStudio usually have to install Eiffel?
- thomas
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.