<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=unicode" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18939"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 bgColor=#ffffff
CanvasTabStop="true" name="Compose message area">
<DIV><FONT face=Arial>The one that could be ported with only minimal work would
be</FONT></DIV><FONT face=Arial>
<DIV><BR><A
title="http://www.tecgraf.puc-rio.br/iup/
CTRL + Click to follow link"
href="http://www.tecgraf.puc-rio.br/iup/">IUP (Portable User
Interface)</A><BR><BR>It looks native on Windows, Motif, and GTK+ and<BR>has a
string-based API which makes it particularly easy to port.</DIV>
<DIV>On Windows it allows only Latin-1 text for the moment, but the</DIV>
<DIV>next version will have a unified UTF-8
interface.<BR><BR>--------------------------------------------------<BR>From:
"Jay K" <jay.krell@cornell.edu><BR>Sent: Tuesday, September 28, 2010 10:47
AM<BR>To: "Darko (M3)" <darko@darko.org><BR>Cc: "m3devel"
<m3devel@elegosoft.com><BR>Subject: Re: [M3devel] UI, Trestle, native...
Cocoa??<BR><BR>> <BR>> > but Mac OS APIs almost never change<BR>>
<BR>> <BR>> Mostly agreed.<BR>> But there can be silent breaks when
only linking gets checked.<BR>> At least libc across various systems has a
bad track record.<BR>> <BR>> <BR>> I think therefore we're talking
about generating wrapper libraries, more or less idiomatic.<BR>> <BR>>
<BR>> > or on Windows the user can change the look whenever they
want.<BR>> <BR>> This is actually allowed for to some extent.<BR>> It
is the point of GetSysColor.<BR>> <BR>> <BR>> "Native" would be good
imho because it just generally looks so much better.<BR>> However it leads to
loss of portability.<BR>> I would really rather see KDE or wxWidgets or
somesuch.<BR>> They do look close to native and do things themselves to
varying degrees.<BR>> <BR>> <BR>> Look at our WinBase.i3 for a feel for
what people have done in the past.<BR>> That is seemingly a direct hand
written translation.<BR>> Do that for a few functions/structs?<BR>> And
then automate it somehow?<BR>> There is "gccxml" that parses headers and
spits out xml, you can then use xml-dom or xsl etc.<BR>> There might also be
enough runtime type information in Macintosh binaries, to save you from parsing
declarations.<BR>> <BR>> <BR>> Realize Carbon is dying to some degree
-- stuff not being ported to 64bit.<BR>> <BR>> <BR>> <BR>> -
Jay<BR>> <BR>> <BR>>
----------------------------------------<BR>>> From:
darko@darko.org<BR>>> Date: Tue, 28 Sep 2010 01:39:40 -0700<BR>>>
To: jay.krell@cornell.edu<BR>>> CC: m3devel@elegosoft.com<BR>>>
Subject: Re: [M3devel] UI, Trestle, native... Cocoa??<BR>>><BR>>> 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.<BR>>><BR>>> 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.<BR>>><BR>>> 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.<BR>>><BR>>><BR>>> On
28/09/2010, at 1:26 AM, Jay K wrote:<BR>>><BR>>> ><BR>>>
> I think you have a few unrelated choices:<BR>>> ><BR>>>
><BR>>> > Make Trestle look like Macintosh when on
Macintosh.<BR>>> > This is altering some low level drawing code, mouse
logic. Doable.<BR>>> > It has little/nothing to do with Objective C or
Cocoa.<BR>>> ><BR>>> ><BR>>> > Wrap other GUI
libraries.<BR>>> > There are many to chose from.<BR>>> > With
more or less idiomatic wrappers.<BR>>> > If you are going to do this,
please do something that runs on more than one system.<BR>>> > KDE,
wxWidgets, FLTK, GTk+, etc.<BR>>> > But GTk+ doesn't seem well
supported on Windows.<BR>>> > KDE would be my choice. It looks good, it
seems to be fairly nice, complete, and evolving fairly rapidly, it has money
behind it.<BR>>> > 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.<BR>>>
><BR>>> ><BR>>> > If you get the hang of things, sure, go
all out, wrap several. Please.<BR>>> ><BR>>> ><BR>>>
> SWIG might be useful here.<BR>>> ><BR>>> ><BR>>>
> Please whatever it is, make sure it gets static checking.<BR>>> >
Assume the C/C++ headers underneath you will change, and you want a compilation
break when that happens. Instead of silent memory corruption.<BR>>>
><BR>>> ><BR>>> > I don't think Trestle implemented on top
of Cocoa makes much sense.<BR>>> > It does make some. Using
CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead
of X Windows.<BR>>> > 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.<BR>>> ><BR>>>
><BR>>> ><BR>>> > - Jay<BR>>> ><BR>>> >
----------------------------------------<BR>>> >> From:
darko@darko.org<BR>>> >> Date: Mon, 27 Sep 2010 23:47:06
-0700<BR>>> >> To: jay.krell@cornell.edu<BR>>> >> CC:
m3devel@elegosoft.com<BR>>> >> Subject: Re: [M3devel] UI, Trestle,
native... Cocoa??<BR>>> >><BR>>> >> 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.<BR>>>
>><BR>>> >><BR>>> >> On 27/09/2010, at 11:38 PM,
Jay K wrote:<BR>>> >><BR>>> >>><BR>>>
>>> I think what is a bit unusual about Trestle is how much it
implements itself.<BR>>> >>><BR>>> >>><BR>>>
>>> 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.<BR>>> >>><BR>>> >>><BR>>>
>>> *and* it is multithreaded.<BR>>> >>> Unusual for GUI
libraries (e.g. Java swing).<BR>>> >>><BR>>>
>>><BR>>> >>> Whenever I read about it, I get lost once
they start talking about the locking protocol.<BR>>>
>>><BR>>> >>><BR>>> >>> The "split"
layout mechanism seems maybe nice.<BR>>> >>> It bugs me how
Windows encouraged pixel count layout and how much fixed size gui there
is.<BR>>> >>><BR>>> >>><BR>>> >>> I
suspect the authors knew or discovered far more than any of us here.<BR>>>
>>><BR>>> >>><BR>>> >>> You probably can
make a decent binding to Cocoa.<BR>>> >>> But I don't
know.<BR>>> >>><BR>>> >>><BR>>> >>>
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?<BR>>>
>>><BR>>> >>><BR>>> >>>> Trestle under
X did not took my breath<BR>>> >>><BR>>>
>>><BR>>> >>> I find Trestle GUI pretty difficult to
interact with.<BR>>> >>> Using scrollbars for
example.<BR>>> >>> I have trouble with most X GUI
actually.<BR>>> >>><BR>>> >>><BR>>>
>>> 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.<BR>>>
>>><BR>>> >>><BR>>> >>> Qt looks very
nice...<BR>>> >>><BR>>> >>><BR>>>
>>> - Jay<BR>>> >>><BR>>> >>>
----------------------------------------<BR>>> >>>> From:
dragisha@m3w.org<BR>>> >>>> To: darko@darko.org<BR>>>
>>>> Date: Tue, 28 Sep 2010 08:23:04 +0200<BR>>>
>>>> CC: m3devel@elegosoft.com<BR>>> >>>> Subject:
Re: [M3devel] UI, Trestle, native... Cocoa??<BR>>>
>>>><BR>>> >>>> I am about to do a port of some
simple (in its GUI aspect) application<BR>>> >>>> to
Mac.<BR>>> >>>><BR>>> >>>> I am also
discouraged (at least tried to) to near death :) by a guy from<BR>>>
>>>> another community, he is 1000% sure Modula-3 cannot be made to
support<BR>>> >>>> Cocoa not a "g" of gracefully.<BR>>>
>>>><BR>>> >>>> Trestle under X did not took my
breath. After peeking and pooking around<BR>>> >>>> sources a
bit, I think it was very nice project in its time, and<BR>>>
>>>> reasonable one to use 12-15yrs ago, but things moved on. In
other words<BR>>> >>>> - I cannot think an explanation to my
customer why a GUI appliction of<BR>>> >>>> mine is not
more.... GUIsh...<BR>>> >>>><BR>>> >>>> I
did a lot of Gtk+ in Modula-3, under Linux (and colleague did his<BR>>>
>>>> testing on Windows while he was working with me on it) and from
that<BR>>> >>>> experience I know it's not impossible to make
native GUI work.<BR>>> >>>><BR>>> >>>> In
other words - count on me for low level binding/interfacing once I<BR>>>
>>>> start doing my work on Mac - in few weeks time.<BR>>>
>>>><BR>>> >>>> On Mon, 2010-09-27 at 13:12 -0700,
Darko wrote:<BR>>> >>>>> 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:<BR>>> >>>>><BR>>>
>>>>> - run time support for Objective-C objects, basically the
ability to call Obj-C methods and reference Obj-C fields in objects<BR>>>
>>>>> - 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).<BR>>>
>>>>><BR>>> >>>>> 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.<BR>>> >>>>><BR>>>
>>>>><BR>>> >>>>> On 25/09/2010, at 1:42 PM,
Dragiša Durić wrote:<BR>>> >>>>><BR>>>
>>>>>> Is it feasible to make it mora native to Mac?
Interesting?<BR>>> >>>>>><BR>>>
>>>>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K
wrote:<BR>>> >>>>>>> It draws all the controls
itself.<BR>>> >>>>>>> The Mac version is the X
Windows version.<BR>>> >>>>>>><BR>>>
>>>>>>> - Jay<BR>>>
>>>>>>><BR>>> >>>>>>>
----------------------------------------<BR>>>
>>>>>>>> From: dragisha@m3w.org<BR>>>
>>>>>>>> To: m3devel@elegosoft.com<BR>>>
>>>>>>>> Date: Sat, 25 Sep 2010 13:41:19
+0200<BR>>> >>>>>>>> Subject: [M3devel] UI,
Trestle, native... Cocoa??<BR>>>
>>>>>>>><BR>>> >>>>>>>>
Anybody working UI's with Trestle? It is mapped no native widgets on<BR>>>
>>>>>>>> Windows? What about Mac?<BR>>>
>>>>>>>> --<BR>>> >>>>>>>>
Dragiša Durić<BR>>> >>>>>>>><BR>>>
>>>>>>><BR>>> >>>>>><BR>>>
>>>>>> --<BR>>> >>>>>> Dragiša
Durić<BR>>> >>>>>><BR>>>
>>>>><BR>>> >>>><BR>>> >>>>
--<BR>>> >>>> Dragiša Durić<BR>>>
>>>><BR>>> >><BR>>></FONT></DIV></BODY></HTML>