[M3devel] UI, Trestle, native... Cocoa??

[Darko]

I think the point is that GUI support for Cocoa and Windows is useful to myself and possibly other people, I'm not really counting how many platforms it will work on - I need those two platforms and I need them native. Actually I need Carbon and Windows right now but Cocoa would be very nice.

Implementing Trestle to look like Cocoa would be non-trivial, and pointless. The idea is that you want your GUI to change when the underlying OS changes, which it does very regularly, or on Windows the user can change the look whenever they want.

As far as static breaks go, there would be links to library calls so when they change the linking would break, but Mac OS APIs almost never change, they just get updated with new calls so it wouldn't really be a problem. I don't know if there is any subtle issues wrt Obj-C but I doubt it. 


On 28/09/2010, at 1:26 AM, Jay K wrote:

> 
> I think you have a few unrelated choices:
> 
> 
> Make Trestle look like Macintosh when on Macintosh.
>   This is altering some low level drawing code, mouse logic. Doable.
>   It has little/nothing to do with Objective C or Cocoa.
> 
> 
> Wrap other GUI libraries.
> There are many to chose from.
> With more or less idiomatic wrappers.
> If you are going to do this, please do something that runs on more than one system.
> KDE, wxWidgets, FLTK, GTk+, etc.
>  But GTk+ doesn't seem well supported on Windows.
>  KDE would be my choice. It looks good, it seems to be fairly nice, complete, and evolving fairly rapidly, it has money behind it.
> An idiomatic wrapper for Cocoa is just one GUI library you could wrap, and it'd have the least value since it only runs on one system. Granted, a slowly growing in popularity system, and iPhone.
> 
> 
> If you get the hang of things, sure, go all out, wrap several. Please.
> 
> 
> SWIG might be useful here.
> 
> 
> Please whatever it is, make sure it gets static checking.
> Assume the C/C++ headers underneath you will change, and you want a compilation break when that happens. Instead of silent memory corruption.
> 
> 
> I don't think Trestle implemented on top of Cocoa makes much sense.
> It does make some. Using CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead of X Windows.
> But given that Trestle draws things itself, "porting" analogous to where the Win32 layer varies from the X layer, wouldn't give you something that looks like Macintosh.
> 
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Mon, 27 Sep 2010 23:47:06 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa??
>> 
>> I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters.
>> 
>> 
>> On 27/09/2010, at 11:38 PM, Jay K wrote:
>> 
>>> 
>>> I think what is a bit unusual about Trestle is how much it implements itself.
>>> 
>>> 
>>> It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events.
>>> 
>>> 
>>> *and* it is multithreaded.
>>> Unusual for GUI libraries (e.g. Java swing).
>>> 
>>> 
>>> Whenever I read about it, I get lost once they start talking about the locking protocol.
>>> 
>>> 
>>> The "split" layout mechanism seems maybe nice.
>>> It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is.
>>> 
>>> 
>>> I suspect the authors knew or discovered far more than any of us here.
>>> 
>>> 
>>> You probably can make a decent binding to Cocoa.
>>> But I don't know.
>>> 
>>> 
>>> Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not?
>>> 
>>> 
>>>> Trestle under X did not took my breath
>>> 
>>> 
>>> I find Trestle GUI pretty difficult to interact with.
>>> Using scrollbars for example.
>>> I have trouble with most X GUI actually.
>>> 
>>> 
>>> The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system.
>>> 
>>> 
>>> Qt looks very nice...
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: dragisha at m3w.org
>>>> To: darko at darko.org
>>>> Date: Tue, 28 Sep 2010 08:23:04 +0200
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa??
>>>> 
>>>> I am about to do a port of some simple (in its GUI aspect) application
>>>> to Mac.
>>>> 
>>>> I am also discouraged (at least tried to) to near death :) by a guy from
>>>> another community, he is 1000% sure Modula-3 cannot be made to support
>>>> Cocoa not a "g" of gracefully.
>>>> 
>>>> Trestle under X did not took my breath. After peeking and pooking around
>>>> sources a bit, I think it was very nice project in its time, and
>>>> reasonable one to use 12-15yrs ago, but things moved on. In other words
>>>> - I cannot think an explanation to my customer why a GUI appliction of
>>>> mine is not more.... GUIsh...
>>>> 
>>>> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his
>>>> testing on Windows while he was working with me on it) and from that
>>>> experience I know it's not impossible to make native GUI work.
>>>> 
>>>> In other words - count on me for low level binding/interfacing once I
>>>> start doing my work on Mac - in few weeks time.
>>>> 
>>>> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote:
>>>>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are:
>>>>> 
>>>>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects
>>>>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces).
>>>>> 
>>>>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web.
>>>>> 
>>>>> 
>>>>> On 25/09/2010, at 1:42 PM, Dragiša Durić wrote:
>>>>> 
>>>>>> Is it feasible to make it mora native to Mac? Interesting?
>>>>>> 
>>>>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote:
>>>>>>> It draws all the controls itself.
>>>>>>> The Mac version is the X Windows version.
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: dragisha at m3w.org
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200
>>>>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa??
>>>>>>>> 
>>>>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on
>>>>>>>> Windows? What about Mac?
>>>>>>>> --
>>>>>>>> Dragiša Durić
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Dragiša Durić
>>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Dragiša Durić
>>>> 
>>