plan9port: cocoa programmer needed

plan9port: cocoa programmer needed

[Russ Cox]

I have updated plan9port to build and run on
OS X Lion.  Everything works except devdraw,
the binary that handles putting windows on the
screen and managing the mouse and keyboard.

Devdraw was written 3 years ago, using the
Carbon framework.  Apple wants to retire
that framework, so they have been slowly
chipping away at its functionality.  It is time to
convert $PLAN9/src/cmd/devdraw/osx-screen-carbon.m
to Cocoa.  There is a previous attempt in osx-screen.m,
but I would not start with that, because it has not kept
up with recent changes (like Multitouch) and bug fixes.
The Carbon source is a better starting point.

Is there anyone out there who knows Cocoa and
Objective C well enough that this would be very easy?
I am sure I could figure it out given enough time,
but enough here is likely quite large.

It would also be nice to convert
$PLAN9/src/cmd/fontsrv/osx.c, but that is
much lower priority, as it appears to build
okay still.

Thanks.
Russ

Re: plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

I was with you till the "very easy" part.  Been following the updates today
and noted that (earlier) the portion of INSTALL that detects the
architecture on Darwin was not working.  Had a patch for that and
regrettably blew it away (accident), then had to turn my attention to
something else.

May try again tomorrow if it persists...

As for the Cocoa bits (mmmm cocoa bits) I might get some time to work that a
bit this weekendif no other takers rise up.

Dave

On Tuesday, August 2, 2011, Russ Cox <rsc@swtch.com> wrote:
> I have updated plan9port to build and run on
> OS X Lion.  Everything works except devdraw,
> the binary that handles putting windows on the
> screen and managing the mouse and keyboard.
>
> Devdraw was written 3 years ago, using the
> Carbon framework.  Apple wants to retire
> that framework, so they have been slowly
> chipping away at its functionality.  It is time to
> convert $PLAN9/src/cmd/devdraw/osx-screen-carbon.m
> to Cocoa.  There is a previous attempt in osx-screen.m,
> but I would not start with that, because it has not kept
> up with recent changes (like Multitouch) and bug fixes.
> The Carbon source is a better starting point.
>
> Is there anyone out there who knows Cocoa and
> Objective C well enough that this would be very easy?
> I am sure I could figure it out given enough time,
> but enough here is likely quite large.
>
> It would also be nice to convert
> $PLAN9/src/cmd/fontsrv/osx.c, but that is
> much lower priority, as it appears to build
> okay still.
>
> Thanks.
> Russ
>

[-- Attachment #2: Type: text/html, Size: 1795 bytes --]

Re: plan9port: cocoa programmer needed

[Russ Cox]

On Wed, Aug 3, 2011 at 12:25 AM, David Leimbach <leimy2k@gmail.com> wrote:
> I was with you till the "very easy" part.  Been following the updates today
> and noted that (earlier) the portion of INSTALL that detects the
> architecture on Darwin was not working.  Had a patch for that and
> regrettably blew it away (accident), then had to turn my attention to
> something else.
>
> May try again tomorrow if it persists...

Should be fixed - there was a missing file that I added
an hour or so after the initial change.

> As for the Cocoa bits (mmmm cocoa bits) I might get some time
> to work that a bit this weekendif no other takers rise up.

Thanks.  I'm surprised how much still works.  It is possible
that we just need to tweak the headers to get Carbon to
build again, but Cocoa is obviously the right long term plan.

Russ

Re: [9fans] plan9port: cocoa programmer needed

[Jeff Sickel]

On Aug 2, 2011, at 3:31 PM, Russ Cox wrote:

> Is there anyone out there who knows Cocoa and
> Objective C well enough that this would be very easy?
> I am sure I could figure it out given enough time,
> but enough here is likely quite large.

The Cocoa API is growing (specifically the length of
their method names, which I think is a ploy to force
developers into buying widescreen monitors that can
handle editing windows with Menlo Regular 11pt fonts
using anywhere between 192 and 1024 character line
lengths).  Hopefully many of the pieces that didn't
work in the earlier osx-screen.m will now be easier to
finish.

If no one else steps up to the plate in the next
month then I should have some time to bang the rocks
together a little bit.

-jas

Re: plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Wed, Aug 3, 2011 at 5:52 AM, Russ Cox <rsc@swtch.com> wrote:

> On Wed, Aug 3, 2011 at 12:25 AM, David Leimbach <leimy2k@gmail.com> wrote:
> > I was with you till the "very easy" part.  Been following the updates
> today
> > and noted that (earlier) the portion of INSTALL that detects the
> > architecture on Darwin was not working.  Had a patch for that and
> > regrettably blew it away (accident), then had to turn my attention to
> > something else.
> >
> > May try again tomorrow if it persists...
>
> Should be fixed - there was a missing file that I added
> an hour or so after the initial change.
>
> > As for the Cocoa bits (mmmm cocoa bits) I might get some time
> > to work that a bit this weekendif no other takers rise up.
>
> Thanks.  I'm surprised how much still works.  It is possible
> that we just need to tweak the headers to get Carbon to
> build again, but Cocoa is obviously the right long term plan.
>
> Russ
>

I'm not able to get to it this weekend as I had planned...

[-- Attachment #2: Type: text/html, Size: 1502 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[andrey mirtchovski]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

i took a gander but i can't help with the build in the time allotted.
here are three old binaries you can use to run acme on lion. export
PATH=$PATH:. to try.

[-- Attachment #2: 9pserve --]
[-- Type: application/octet-stream, Size: 151572 bytes --]

[-- Attachment #3: acme --]
[-- Type: application/octet-stream, Size: 482036 bytes --]

[-- Attachment #4: devdraw --]
[-- Type: application/octet-stream, Size: 265980 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> It is possible that we just need to tweak the
> headers to get Carbon to build again, but Cocoa is
> obviously the right long term plan.

I have a "working" Cocoa version of Devdraw for
OS X Lion: I'm using it with Acme to write this email.

There is just the bare minimum:

	no menu but 'Quit',
	no fullscreen but OS X Lion's fullscreen,
	no "Multitouch" support.

It answers to the following gesture events though:

	swipe-left to cut (cmd+x),
	swipe-right to paste (cmd+v),
	swipe-up to execute (button 2),
	swipe-down to execute with arguments (2-1 chord),
	pinch to toggle fullscreen.

I will send my code at the end of next week: I
still need time to clean it and to try to resolve
some imperfections and inconsistencies.

Re: [9fans] plan9port: cocoa programmer needed

[Russ Cox]

wow, thanks!

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Thu, Aug 25, 2011 at 11:33 AM, david jeannot <djeannot24@gmail.com>wrote:

> > It is possible that we just need to tweak the
> > headers to get Carbon to build again, but Cocoa is
> > obviously the right long term plan.
>
> I have a "working" Cocoa version of Devdraw for
> OS X Lion: I'm using it with Acme to write this email.
>
> There is just the bare minimum:
>
>        no menu but 'Quit',
>        no fullscreen but OS X Lion's fullscreen,
>        no "Multitouch" support.
>
> It answers to the following gesture events though:
>
>        swipe-left to cut (cmd+x),
>        swipe-right to paste (cmd+v),
>        swipe-up to execute (button 2),
>        swipe-down to execute with arguments (2-1 chord),
>        pinch to toggle fullscreen.
>
> I will send my code at the end of next week: I
> still need time to clean it and to try to resolve
> some imperfections and inconsistencies.
>
> Sounds pretty awesome!

[-- Attachment #2: Type: text/html, Size: 1314 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[Steve McCoy]

Oh man, the gestures sound great!

Re: [9fans] plan9port: cocoa programmer needed

[Russ Cox]

On Thu, Aug 25, 2011 at 2:33 PM, david jeannot <djeannot24@gmail.com> wrote:
>> It is possible that we just need to tweak the
>> headers to get Carbon to build again, but Cocoa is
>> obviously the right long term plan.
>
> I have a "working" Cocoa version of Devdraw for
> OS X Lion: I'm using it with Acme to write this email.
>
> There is just the bare minimum:
>
>        no menu but 'Quit',
>        no fullscreen but OS X Lion's fullscreen,
>        no "Multitouch" support.
>
> It answers to the following gesture events though:
>
>        swipe-left to cut (cmd+x),
>        swipe-right to paste (cmd+v),
>        swipe-up to execute (button 2),
>        swipe-down to execute with arguments (2-1 chord),
>        pinch to toggle fullscreen.
>
> I will send my code at the end of next week: I
> still need time to clean it and to try to resolve
> some imperfections and inconsistencies.

This sounds very cool.  Did you figure out a way
to let acme move the mouse cursor the way it
wants to?

Russ

Re: [9fans] plan9port: cocoa programmer needed

[Salman Aljammaz]

>        swipe-left to cut (cmd+x),
>        swipe-right to paste (cmd+v),
>        swipe-up to execute (button 2),
>        swipe-down to execute with arguments (2-1 chord),
>        pinch to toggle fullscreen.

nice!  and only 2 days after i stopped using os x...

i'll have a stab at doing something similar on linux.

http://www.synaptics.com/solutions/technology/gestures/touchpad-linux

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> This sounds very cool.  Did you figure out a way
> to let acme move the mouse cursor the way it wants
> to?

Yes: Devdraw's setmouse() is implemented.

Yesterday I said: "There is just the bare minimum".

I should have said: "There is almost everything if
you use OS X Lion".  (There is still mouse
support, the alt and cmd keys still simulate mouse
buttons, etc.)


A thing that annoy me since yesterday is that a
cut (cmd+x) immediately followed by a paste
(cmd+v) leaves a "clean" Acme's window "dirty".
We could maybe send a cmd+u instead of a cmd+v
when the fingers remain on the tactile device
between the left-swipe and the right-swipe, that
Acme would interpret as "Undo", if there is no
simpler way.  Or we could just use another gesture
to copy (cmd+c), but there would be no feedback.

Another thing that annoy me is that I receive
swipe-up and swipe-down events only if I disable
the OS X application BetterTouchTool, that I
configured to instruct Google Chrome, and Google
Chrome only, to create a new tab when I swipe-up,
and to close the current tab when I swipe-down.
Does anyone know how BetterTouchTool is
implemented?  A BetterTouchTool-like 9p server
might be a good solution :)

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

Does anyone acquainted with Acme's code have a
little time to add support for cmd+z (undo), and
to post the resulting binary (compatible OS X
Lion)?

According to my quick tests on Linux, the following
seems to work:

	/usr/local/plan9/src/cmd/acme/text.c:754
		case Kcmd+'c':	/* %C: copy */
			typecommit(t);
			cut(t, t, nil, TRUE, FALSE, nil, 0);
			return;
	+	case Kcmd+'z':	/* %Z: undo */
	+		typecommit(t);
	+		undo(t, nil, nil, TRUE, 0, nil, 0);
	+		return;

(Lion is the only OS X version I have, and
apparently, all that I compile on it based on
libthread doesn't work.)

Devdraw is ready to send cmd+z (undo) when a right
swipe follows a left swipe (and vice versa), if
the fingers remained on the tactile device in
between.

Re: [9fans] plan9port: cocoa programmer needed

[Russ Cox]

> According to my quick tests on Linux, the following
> seems to work:
>
>        /usr/local/plan9/src/cmd/acme/text.c:754
>                case Kcmd+'c':  /* %C: copy */
>                        typecommit(t);
>                        cut(t, t, nil, TRUE, FALSE, nil, 0);
>                        return;
>        +       case Kcmd+'z':  /* %Z: undo */
>        +               typecommit(t);
>        +               undo(t, nil, nil, TRUE, 0, nil, 0);
>        +               return;
>
> (Lion is the only OS X version I have, and
> apparently, all that I compile on it based on
> libthread doesn't work.)

hget http://swtch.com/~rsc/acme >acme
is a Snow Leopard-compiled acme.  It should work fine.

I thought threaded programs worked on Lion when
I started this thread.  When you send me your
devdraw fixes I will make sure a Lion-compiled
acme runs.  Sorry for the trouble.

Russ

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

>> Devdraw is ready to send cmd+z (undo) when a right
>> swipe follows a left swipe (and vice versa), if
>> the fingers remained on the tactile device in
>> between.

>> Does anyone acquainted with Acme's code have a
>> little time to add support for cmd+z (undo), and
>> to post the resulting binary (compatible OS X
>> Lion)?


> hget http://swtch.com/~rsc/acme >acme
> is a Snow Leopard-compiled acme.  It should work fine.


Thank you so much Russ: now the horizontal swipe
gestures cancel each other.

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

Last week I said:

	I will send my code at the end of next week: I
	still need time to clean it and to try to resolve
	some imperfections and inconsistencies.

I'll be late.


Last week I also said:

	Another thing that annoy me is that I receive
	swipe-up and swipe-down events only if I disable
	the OS X application BetterTouchTool

I believed that BetterTouchTool was the culprit,
but it is the opposite.  Since Lion, OS X only
sends horizontal swipe events: it doesn't send
vertical swipe events anymore.  I discovered that
yesterday, after uninstalling BetterTouchTool.
And there is apparently no official way to receive
them: it seems to be a bug.  I don't know why I
receive them (more or less) when BetterTouchTool
is in disable mode.

I will try to detect vertical swipe gestures with
lower level events: it doesn't seem too difficult.


And then, urgent matters prevented me to implement
setcursor() and to rework the "flush image to
screen" code.


So I will send my code in the next few days,
unless there is a need.

Re: [9fans] plan9port: cocoa programmer needed

[Russ Cox]

David's new Cocoa devdraw is in the plan9port tree now,
but not built by default.  There are still some rough
edges to work out.  If you want to play and maybe
find and fix bugs, you can use

cd $PLAN9/src/cmd/devdraw
mk cocoa
export DEVDRAW=$PLAN9/src/cmd/devdraw/cocoa
colors
acme
sam
whatever

Russ

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

YES!  This is great.

On Tue, Sep 6, 2011 at 7:16 AM, Russ Cox <rsc@swtch.com> wrote:

> David's new Cocoa devdraw is in the plan9port tree now,
> but not built by default.  There are still some rough
> edges to work out.  If you want to play and maybe
> find and fix bugs, you can use
>
> cd $PLAN9/src/cmd/devdraw
> mk cocoa
> export DEVDRAW=$PLAN9/src/cmd/devdraw/cocoa
> colors
> acme
> sam
> whatever
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 725 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[Aram Hăvărneanu]

> David's new Cocoa devdraw is in the plan9port tree now,
> but not built by default.
>
> cd $PLAN9/src/cmd/devdraw
> mk cocoa

ld: in /Users/aram/plan9/lib/libbio.a, malformed archive TOC entry for
_Bwrite, offset 538981428 is beyond end of file 80716
 for architecture x86_64

gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)

Some other people on IRC get this too.

Do I need a different XCode?

-- 
Aram Hăvărneanu

Re: [9fans] plan9port: cocoa programmer needed

[Russ Cox]

Try adding

# HA HA HA.  Apple broke things again.
[ "$SYSNAME" != "Darwin" ] || ranlib $2

to the bottom of $PLAN9/bin/9ar

Re: [9fans] plan9port: cocoa programmer needed

[Aram Hăvărneanu]

> Try adding
>
> # HA HA HA.  Apple broke things again.
> [ "$SYSNAME" != "Darwin" ] || ranlib $2
>
> to the bottom of $PLAN9/bin/9ar
>

Cocoa bits build this way, but other things don't.

Here's a log: http://pastebin.com/mh5Z6xrf

-- 
Aram Hăvărneanu

Re: [9fans] plan9port: cocoa programmer needed

[Jeff Sickel]

Nice handling of the Glenda icon.

Using Xcode 4.1 on Lion I get different errors (libstdio is another problem as FPdbleword is no longer defined) so I'm still not rebuilding everything.  9c picks up:

gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)


9c -DMULTITOUCH -o cocoa-screen-objc.o cocoa-screen.m
cocoa-screen.m:712: error: cannot convert to a pointer type
cocoa-screen.m:712: error: incompatible type for argument 1 of ‘CGWarpMouseCursorPosition’

Corrected that would be:
% hg diff .
diff -r d92a37e64563 src/cmd/devdraw/cocoa-screen.m
--- a/src/cmd/devdraw/cocoa-screen.m	Tue Sep 06 10:10:43 2011 -0400
+++ b/src/cmd/devdraw/cocoa-screen.m	Tue Sep 06 11:08:04 2011 -0500
@@ -709,7 +709,7 @@
 	q = [win.obj convertBaseToScreen:q];
 	q.y = r.size.height - q.y;
 
-	CGWarpMouseCursorPosition(q);
+	CGWarpMouseCursorPosition(NSPointToCGPoint(q));
 
 //	race condition
 	mpos = p;


On Sep 6, 2011, at 11:03 AM, Russ Cox wrote:

> Try adding
> 
> # HA HA HA.  Apple broke things again.
> [ "$SYSNAME" != "Darwin" ] || ranlib $2
> 
> to the bottom of $PLAN9/bin/9ar
> 
> 

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

It built ok here, but sam, and acme aren't doing anything terribly
interesting (well maybe it is interesting, but they're crashing, presumably
logging something to somewhere interesting).

I'll keep poking when I'm not at work later.

Dave

On Tue, Sep 6, 2011 at 9:26 AM, Jeff Sickel <jas@corpus-callosum.com> wrote:

> Nice handling of the Glenda icon.
>
> Using Xcode 4.1 on Lion I get different errors (libstdio is another problem
> as FPdbleword is no longer defined) so I'm still not rebuilding everything.
>  9c picks up:
>
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
>
>
> 9c -DMULTITOUCH -o cocoa-screen-objc.o cocoa-screen.m
> cocoa-screen.m:712: error: cannot convert to a pointer type
> cocoa-screen.m:712: error: incompatible type for argument 1 of
> ‘CGWarpMouseCursorPosition’
>
> Corrected that would be:
> % hg diff .
> diff -r d92a37e64563 src/cmd/devdraw/cocoa-screen.m
> --- a/src/cmd/devdraw/cocoa-screen.m    Tue Sep 06 10:10:43 2011 -0400
> +++ b/src/cmd/devdraw/cocoa-screen.m    Tue Sep 06 11:08:04 2011 -0500
> @@ -709,7 +709,7 @@
>        q = [win.obj convertBaseToScreen:q];
>        q.y = r.size.height - q.y;
>
> -       CGWarpMouseCursorPosition(q);
> +       CGWarpMouseCursorPosition(NSPointToCGPoint(q));
>
>  //     race condition
>        mpos = p;
>
>
> On Sep 6, 2011, at 11:03 AM, Russ Cox wrote:
>
> > Try adding
> >
> > # HA HA HA.  Apple broke things again.
> > [ "$SYSNAME" != "Darwin" ] || ranlib $2
> >
> > to the bottom of $PLAN9/bin/9ar
> >
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 2080 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[Latchesar Ionkov]

I get the same errors.

Thanks,
    Lucho

On Tue, Sep 6, 2011 at 10:25 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
>> Try adding
>>
>> # HA HA HA.  Apple broke things again.
>> [ "$SYSNAME" != "Darwin" ] || ranlib $2
>>
>> to the bottom of $PLAN9/bin/9ar
>>
>
> Cocoa bits build this way, but other things don't.
>
> Here's a log: http://pastebin.com/mh5Z6xrf
>
> --
> Aram Hăvărneanu
>
>

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

You have to then rebuild everything.

On Tue, Sep 6, 2011 at 11:34 AM, Latchesar Ionkov <lucho@ionkov.net> wrote:

> I get the same errors.
>
> Thanks,
>    Lucho
>
> On Tue, Sep 6, 2011 at 10:25 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
> >> Try adding
> >>
> >> # HA HA HA.  Apple broke things again.
> >> [ "$SYSNAME" != "Darwin" ] || ranlib $2
> >>
> >> to the bottom of $PLAN9/bin/9ar
> >>
> >
> > Cocoa bits build this way, but other things don't.
> >
> > Here's a log: http://pastebin.com/mh5Z6xrf
> >
> > --
> > Aram Hăvărneanu
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1101 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[Latchesar Ionkov]

I get the errors when I run ./INSTALL

Thanks,
    Lucho

On Tue, Sep 6, 2011 at 12:54 PM, David Leimbach <leimy2k@gmail.com> wrote:
> You have to then rebuild everything.
>
> On Tue, Sep 6, 2011 at 11:34 AM, Latchesar Ionkov <lucho@ionkov.net> wrote:
>>
>> I get the same errors.
>>
>> Thanks,
>>    Lucho
>>
>> On Tue, Sep 6, 2011 at 10:25 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
>> >> Try adding
>> >>
>> >> # HA HA HA.  Apple broke things again.
>> >> [ "$SYSNAME" != "Darwin" ] || ranlib $2
>> >>
>> >> to the bottom of $PLAN9/bin/9ar
>> >>
>> >
>> > Cocoa bits build this way, but other things don't.
>> >
>> > Here's a log: http://pastebin.com/mh5Z6xrf
>> >
>> > --
>> > Aram Hăvărneanu
>> >
>> >
>>
>
>

Re: [9fans] plan9port: cocoa programmer needed

[Russ Cox]

I am using Xcode 4.2 on Lion without problems.
Can you try updating to the newer Xcode?

Russ

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

I have a temporary solution.  As soon as INSTALL
finishes to compile the libraries (*/src/lib*),
do:

	ranlib yourplan9/lib/*.a

The rest should compile successfully.

When I found this hack, I also tried to add ranlib
to bin/9ar, as Russ suggested, but I got the same
errors as you have.

I just tried both methods, and I still have the
same results.

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

I'm using 4.1 currently, will try updating.  Everything builds fine, but
some stuff doesn't run.

On Tue, Sep 6, 2011 at 12:37 PM, Russ Cox <rsc@swtch.com> wrote:

> I am using Xcode 4.2 on Lion without problems.
> Can you try updating to the newer Xcode?
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 548 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

4.1 is the latest release of Xcode by the way.  4.2 is for Apple devs who
pay (according to the site anyway).

Dave

On Tue, Sep 6, 2011 at 12:41 PM, David Leimbach <leimy2k@gmail.com> wrote:

> I'm using 4.1 currently, will try updating.  Everything builds fine, but
> some stuff doesn't run.
>
>
> On Tue, Sep 6, 2011 at 12:37 PM, Russ Cox <rsc@swtch.com> wrote:
>
>> I am using Xcode 4.2 on Lion without problems.
>> Can you try updating to the newer Xcode?
>>
>> Russ
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1068 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[andrey mirtchovski]

the latest XCode available in the app store is 4.1.1

the latest developer preview is iOS 5 beta (which comes with Xcode 4.2)

Re: [9fans] plan9port: cocoa programmer needed

[andrey mirtchovski]

> the latest developer preview is iOS 5 beta (which comes with Xcode 4.2)

sorry, this doesn't make much sense. i mean 'the latest developer
preview advertised by apple is for iOS5 beta, which comes with Xcode
4.2'

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> I'm using 4.1 currently, will try updating.
> Everything builds fine, but some stuff doesn't
> run.

On my system (Lion + XCode 4.1), all that is based
on Libthread doesn't run.  So I'm testing Devdraw
with binaries coming from Snow Leopard (thank you
Andrey and Russ for those you have joined to this
topic).


> -       CGWarpMouseCursorPosition(q);
> +       CGWarpMouseCursorPosition(NSPointToCGPoint(q));

Thanks.


(I would be interested to know if the swipe-down
and swipe-up gestures, that send exec with or
without args to Acme, work on Snow Leopard.)

Re: [9fans] plan9port: cocoa programmer needed

[andrey mirtchovski]

well, i managed to compile everything using some combination of ranlib
$PLAN9/bin/lib/*, mk nuke and mk all. i think it goes like this:

run ./INSTALL, see it crash
run 'mk all' in $PLAN9/src/cmd & get arch errors as above
run "ranlib $PLAN9/lib/*.a"
run  'mk all' in $PLAN9/src/cmd & get TOC errors instead
run "ranlib $PLAN9/lib/*.a"
now mk all compiles...

strange? this does not work if I do ranlib on each .a file individually.

as for devdraw, i get crashes for acme. colors works but doesn't
display text for each color, tcolors gives this short message
(devdraw-cocoa instead of just cocoa):

$ tcolors
2011-09-06 14:22:28.501 devdraw[95453:707] here
2011-09-06 14:22:28.505 devdraw[95453:707] setShowsApplicationBadge:
is not yet implemented for the NSApp dockTile
<- tag=1 Tinit label='colors' winsize=''
2011-09-06 14:22:28.524 devdraw[95453:707] here
2011-09-06 14:22:28.526 devdraw[95453:707] setShowsApplicationBadge:
is not yet implemented for the NSApp dockTile
-> tag=1 Rinit
<- tag=1 Twrdraw 2 %H%
-> tag=1 Rwrdraw 2
<- tag=1 Trddraw 145
-> tag=1 Rrddraw 144 %H%
<- tag=1 Twrdraw 51 %H%
-> tag=1 Rwrdraw 51
<- tag=1 Twrdraw 51 %H%
-> tag=1 Rwrdraw 51
<- tag=1 Twrdraw 51 %H%
-> tag=1 Rwrdraw 51
<- tag=1 Twrdraw 4341 %H%
-> tag=1 Rwrdraw 4341
<- tag=1 Twrdraw 14 %H%
-> tag=1 Rwrdraw 14
<- tag=1 Twrdraw 51 %H%
-> tag=1 Rwrdraw 51
<- tag=1 Twrdraw 46 %H%
-> tag=1 Rwrdraw 46
<- tag=1 Twrdraw 51 %H%
-> tag=1 Rwrdraw 51
<- tag=2 Trdmouse
Bus error: 10

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> So I will send my code in the next few days,
> unless there is a need.

I'm 9 days late, but here it is: the Cocoa version
of Devdraw.  I just submitted it to Codereview:

	http://codereview.appspot.com/5015042

I removed live resizing, because I found no way to
make it perfect: the window now becomes gray while
resizing.


About gestures now.

A swipe gesture needs 3 fingers (with trackpads at
least).  If you want to use them, you must
reconfigure OS X Lion to use 4 fingers instead of
3 (to swipe between spaces, or to swipe to
"Mission Control" for example).

As previously discussed, OS X Lion doesn't send
swipe events anymore for vertical swipes.  So I
reimplemented swipe gestures with lower-level
touch events.  All that I can say is that it works
well with a late 2010 MacBook Air's trackpad.
Unfortunately, it seems only for trackpads: not
for "Magic Mouse".  The higher-level gesture
events seem compatible with "Magic Mouse" (though
I don't know to how many fingers a swipe gesture
corresponds), but the lower-level touch events
seem incompatible (I may be mistaken).

If you want to use the reimplemented swipes, you
have to set the "reimplementswipe" variable at the
beginning of cocoa-screen.m (the file's name may
change soon).

One advantage of this reimplementation is that we
can now detect 3-finger taps.  If you set the
"usecopygesture" variable as well, you have now
the following gestures:

	3-finger swipe-left to cut (cmd+x),
	3-finger swipe-right to paste (cmd+v),
	3-finger swipe-up to copy (cmd+c),
	3-finger swipe-down to execute with arguments (2-1 chord),
	3-finger tap to execute (button 2),
	pinch to toggle fullscreen.

Else you have:

       swipe-left to cut (cmd+x),
       swipe-right to paste (cmd+v),
       swipe-up to execute (button 2),
       swipe-down to execute with arguments (2-1 chord),
       pinch to toggle fullscreen.

In both cases, horizontal swipes cancel each
other if your fingers remain on the device in
between.  That is to say, the second swipe sends
undo (cmd+z): a command only recognized by Acme
currently.  An annoyance is the behavior of Acme's
Undo when we are in the window's tag.  Acme only
seems to undo filename change, else it undoes the
last change in the window's body.  For example, if
you want to copy from the tag, (unless you use the
copy gesture) you will have to lift the fingers
between the left and the right swipe, else it will
undo the window's body, and you will be completely
puzzled.

I wish this announcement will not cause too much
disappointment among "Magic Mouse" users.  I knew
nothing of Mac programming before to begin this
project one month ago, and I certainly generalize
too much.  (I didn't understood what was the
mysterious "multitouch" code in Carbon's Devdraw,
until some days ago, where I fell upon a similar
code to communicate with the "Magic Mouse" here:
http://www.iphonesmartapps.org/aladino/?a=multitouch)


If OS X Lion's users prefer the old fullscreen
mode, they can set the "useoldfullscreen"
variable.

(Currently, Devdraw can't accept arguments, and as
it is so hard to compile anything with current
Xcode 4.1, I didn't try to modify Libdraw.  This
is why you have to set variables instead of using
optional arguments.)


Be sure to read the description on Codereview for
the remaining bugs, to avoid further
disappointment.


If you need binaries running on Lion (Cocoa's
Devdraw, Acme supporting "cmd+z", etc.), I will be
happy to provide them.

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 3918 bytes --]

Thanks for all of your work on this!

On Tue, Sep 13, 2011 at 8:59 AM, david jeannot <djeannot24@gmail.com> wrote:

> > So I will send my code in the next few days,
> > unless there is a need.
>
> I'm 9 days late, but here it is: the Cocoa version
> of Devdraw.  I just submitted it to Codereview:
>
>        http://codereview.appspot.com/5015042
>
> I removed live resizing, because I found no way to
> make it perfect: the window now becomes gray while
> resizing.
>
>
> About gestures now.
>
> A swipe gesture needs 3 fingers (with trackpads at
> least).  If you want to use them, you must
> reconfigure OS X Lion to use 4 fingers instead of
> 3 (to swipe between spaces, or to swipe to
> "Mission Control" for example).
>
> As previously discussed, OS X Lion doesn't send
> swipe events anymore for vertical swipes.  So I
> reimplemented swipe gestures with lower-level
> touch events.  All that I can say is that it works
> well with a late 2010 MacBook Air's trackpad.
> Unfortunately, it seems only for trackpads: not
> for "Magic Mouse".  The higher-level gesture
> events seem compatible with "Magic Mouse" (though
> I don't know to how many fingers a swipe gesture
> corresponds), but the lower-level touch events
> seem incompatible (I may be mistaken).
>
> If you want to use the reimplemented swipes, you
> have to set the "reimplementswipe" variable at the
> beginning of cocoa-screen.m (the file's name may
> change soon).
>
> One advantage of this reimplementation is that we
> can now detect 3-finger taps.  If you set the
> "usecopygesture" variable as well, you have now
> the following gestures:
>
>        3-finger swipe-left to cut (cmd+x),
>        3-finger swipe-right to paste (cmd+v),
>        3-finger swipe-up to copy (cmd+c),
>        3-finger swipe-down to execute with arguments (2-1 chord),
>        3-finger tap to execute (button 2),
>        pinch to toggle fullscreen.
>
> Else you have:
>
>       swipe-left to cut (cmd+x),
>       swipe-right to paste (cmd+v),
>       swipe-up to execute (button 2),
>       swipe-down to execute with arguments (2-1 chord),
>       pinch to toggle fullscreen.
>
> In both cases, horizontal swipes cancel each
> other if your fingers remain on the device in
> between.  That is to say, the second swipe sends
> undo (cmd+z): a command only recognized by Acme
> currently.  An annoyance is the behavior of Acme's
> Undo when we are in the window's tag.  Acme only
> seems to undo filename change, else it undoes the
> last change in the window's body.  For example, if
> you want to copy from the tag, (unless you use the
> copy gesture) you will have to lift the fingers
> between the left and the right swipe, else it will
> undo the window's body, and you will be completely
> puzzled.
>
> I wish this announcement will not cause too much
> disappointment among "Magic Mouse" users.  I knew
> nothing of Mac programming before to begin this
> project one month ago, and I certainly generalize
> too much.  (I didn't understood what was the
> mysterious "multitouch" code in Carbon's Devdraw,
> until some days ago, where I fell upon a similar
> code to communicate with the "Magic Mouse" here:
> http://www.iphonesmartapps.org/aladino/?a=multitouch)
>
>
> If OS X Lion's users prefer the old fullscreen
> mode, they can set the "useoldfullscreen"
> variable.
>
> (Currently, Devdraw can't accept arguments, and as
> it is so hard to compile anything with current
> Xcode 4.1, I didn't try to modify Libdraw.  This
> is why you have to set variables instead of using
> optional arguments.)
>
>
> Be sure to read the description on Codereview for
> the remaining bugs, to avoid further
> disappointment.
>
>
> If you need binaries running on Lion (Cocoa's
> Devdraw, Acme supporting "cmd+z", etc.), I will be
> happy to provide them.
>
>

[-- Attachment #2: Type: text/html, Size: 4724 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[Jeff Sickel]

David,

So far my testing on your prior version worked
decently on Lion (linked against Snowy built
9libs).  Once this new version shows up in the
source tree I'll be able to test a little more.

One issue I did not w/ acme: screen redraw is
significantly slower than the Carbon version.
Test by starting win in acme and doing something
that creates a long listing (netstat, ps,...).
Not a big issue as this can be fixed later.

Thanks for the code.

-jas

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> One issue I did not w/ acme: screen redraw is
> significantly slower than the Carbon version.
> Test by starting win in acme and doing something
> that creates a long listing (netstat, ps,...).
> Not a big issue as this can be fixed later.

Yes, it was very painful, but the new version is
very responsive.  (The only way I had found to
deal with "live resizing" compelled Devdraw to
swap the back buffer and the front buffer each
time plan9 was flushing rectangles to the back
buffer, and dreadful was the latency.)

Just after my "I will be late" announcement, Russ
advised me to publish all the same what I had,
because Carbon's Devdraw apparently also stopped
working on Snow Leopard with the latest Xcode.  I
was in the middle of "live resizing" madness, and
my code was very experimental, but I forgot to
mention it on 9fans.


Sent from my gesture-enhanced Acme.

Re: [9fans] plan9port: cocoa programmer needed

[hiro]

Can you guys perhaps create a small video about how you use your
computers now? It's difficult to understand for someone who doesn't
own a mac, but I would still like to see what you're doing there ;)

On Wed, Sep 14, 2011 at 18:40, david jeannot <djeannot24@gmail.com> wrote:
>> One issue I did not w/ acme: screen redraw is
>> significantly slower than the Carbon version.
>> Test by starting win in acme and doing something
>> that creates a long listing (netstat, ps,...).
>> Not a big issue as this can be fixed later.
>
> Yes, it was very painful, but the new version is
> very responsive.  (The only way I had found to
> deal with "live resizing" compelled Devdraw to
> swap the back buffer and the front buffer each
> time plan9 was flushing rectangles to the back
> buffer, and dreadful was the latency.)
>
> Just after my "I will be late" announcement, Russ
> advised me to publish all the same what I had,
> because Carbon's Devdraw apparently also stopped
> working on Snow Leopard with the latest Xcode.  I
> was in the middle of "live resizing" madness, and
> my code was very experimental, but I forgot to
> mention it on 9fans.
>
>
> Sent from my gesture-enhanced Acme.
>
>

Re: [9fans] plan9port: cocoa programmer needed

[John Floren]

On Tue, Sep 13, 2011 at 8:59 AM, david jeannot <djeannot24@gmail.com> wrote:
>> So I will send my code in the next few days,
>> unless there is a need.
>
> I'm 9 days late, but here it is: the Cocoa version
> of Devdraw.  I just submitted it to Codereview:
>
>        http://codereview.appspot.com/5015042
>
> I removed live resizing, because I found no way to
> make it perfect: the window now becomes gray while
> resizing.
>
>
> About gestures now.
>
> A swipe gesture needs 3 fingers (with trackpads at
> least).  If you want to use them, you must
> reconfigure OS X Lion to use 4 fingers instead of
> 3 (to swipe between spaces, or to swipe to
> "Mission Control" for example).
>
> As previously discussed, OS X Lion doesn't send
> swipe events anymore for vertical swipes.  So I
> reimplemented swipe gestures with lower-level
> touch events.  All that I can say is that it works
> well with a late 2010 MacBook Air's trackpad.
> Unfortunately, it seems only for trackpads: not
> for "Magic Mouse".  The higher-level gesture
> events seem compatible with "Magic Mouse" (though
> I don't know to how many fingers a swipe gesture
> corresponds), but the lower-level touch events
> seem incompatible (I may be mistaken).
>
> If you want to use the reimplemented swipes, you
> have to set the "reimplementswipe" variable at the
> beginning of cocoa-screen.m (the file's name may
> change soon).
>
> One advantage of this reimplementation is that we
> can now detect 3-finger taps.  If you set the
> "usecopygesture" variable as well, you have now
> the following gestures:
>
>        3-finger swipe-left to cut (cmd+x),
>        3-finger swipe-right to paste (cmd+v),
>        3-finger swipe-up to copy (cmd+c),
>        3-finger swipe-down to execute with arguments (2-1 chord),
>        3-finger tap to execute (button 2),
>        pinch to toggle fullscreen.
>
> Else you have:
>
>       swipe-left to cut (cmd+x),
>       swipe-right to paste (cmd+v),
>       swipe-up to execute (button 2),
>       swipe-down to execute with arguments (2-1 chord),
>       pinch to toggle fullscreen.
>
> In both cases, horizontal swipes cancel each
> other if your fingers remain on the device in
> between.  That is to say, the second swipe sends
> undo (cmd+z): a command only recognized by Acme
> currently.  An annoyance is the behavior of Acme's
> Undo when we are in the window's tag.  Acme only
> seems to undo filename change, else it undoes the
> last change in the window's body.  For example, if
> you want to copy from the tag, (unless you use the
> copy gesture) you will have to lift the fingers
> between the left and the right swipe, else it will
> undo the window's body, and you will be completely
> puzzled.
>
> I wish this announcement will not cause too much
> disappointment among "Magic Mouse" users.  I knew
> nothing of Mac programming before to begin this
> project one month ago, and I certainly generalize
> too much.  (I didn't understood what was the
> mysterious "multitouch" code in Carbon's Devdraw,
> until some days ago, where I fell upon a similar
> code to communicate with the "Magic Mouse" here:
> http://www.iphonesmartapps.org/aladino/?a=multitouch)
>
>
> If OS X Lion's users prefer the old fullscreen
> mode, they can set the "useoldfullscreen"
> variable.
>
> (Currently, Devdraw can't accept arguments, and as
> it is so hard to compile anything with current
> Xcode 4.1, I didn't try to modify Libdraw.  This
> is why you have to set variables instead of using
> optional arguments.)
>
>
> Be sure to read the description on Codereview for
> the remaining bugs, to avoid further
> disappointment.
>
>
> If you need binaries running on Lion (Cocoa's
> Devdraw, Acme supporting "cmd+z", etc.), I will be
> happy to provide them.
>
>

I just inherited a Macbook running Lion, so this is suddenly relevant
to my interests. I'm very new to the world of OS X; could somebody put
together a step-by-step on how to build for Lion? I've downloaded the
plan9ports tarball, extracted it to /usr/local/plan9, and done an hg
pull -u, but INSTALL dies with complaints from ld about a malformed
TOC entry in libbio.a. Also, further up, when it tries to build
devdraw I see it failing because it still tries to make the Carbon
version.


John

Re: [9fans] plan9port: cocoa programmer needed

[andrey mirtchovski]

add:

[ "$SYSNAME" != "Darwin" ] || ranlib $2

to the bottom of $PLAN9/bin/9ar

then cd src/cmd/devdraw && mk cocoa && cp cocoa $PLAN9/bin/devdraw

now you're as far as I got :) i'm trying to figure out why 'colors'
works, but acme exits with return value of 1.

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Wed, Sep 14, 2011 at 10:23 AM, andrey mirtchovski
<mirtchovski@gmail.com>wrote:

> add:
>
> [ "$SYSNAME" != "Darwin" ] || ranlib $2
>
> to the bottom of $PLAN9/bin/9ar
>
> then cd src/cmd/devdraw && mk cocoa && cp cocoa $PLAN9/bin/devdraw
>
> now you're as far as I got :) i'm trying to figure out why 'colors'
> works, but acme exits with return value of 1.
>
> I have the same results.

[-- Attachment #2: Type: text/html, Size: 734 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[ron minnich]

On Wed, Sep 14, 2011 at 10:28 AM, David Leimbach <leimy2k@gmail.com> wrote:
>
>
> On Wed, Sep 14, 2011 at 10:23 AM, andrey mirtchovski <mirtchovski@gmail.com>
> wrote:
>>
>> add:
>>
>> [ "$SYSNAME" != "Darwin" ] || ranlib $2
>>
>> to the bottom of $PLAN9/bin/9ar
>>
>> then cd src/cmd/devdraw && mk cocoa && cp cocoa $PLAN9/bin/devdraw
>>
>> now you're as far as I got :) i'm trying to figure out why 'colors'
>> works, but acme exits with return value of 1.
>>
> I have the same results.

anything useful from truss?

ron

Re: [9fans] plan9port: cocoa programmer needed

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On Wed, Sep 14, 2011 at 10:31 AM, ron minnich <rminnich@gmail.com> wrote:

> On Wed, Sep 14, 2011 at 10:28 AM, David Leimbach <leimy2k@gmail.com>
> wrote:
> >
> >
> > On Wed, Sep 14, 2011 at 10:23 AM, andrey mirtchovski <
> mirtchovski@gmail.com>
> > wrote:
> >>
> >> add:
> >>
> >> [ "$SYSNAME" != "Darwin" ] || ranlib $2
> >>
> >> to the bottom of $PLAN9/bin/9ar
> >>
> >> then cd src/cmd/devdraw && mk cocoa && cp cocoa $PLAN9/bin/devdraw
> >>
> >> now you're as far as I got :) i'm trying to figure out why 'colors'
> >> works, but acme exits with return value of 1.
> >>
> > I have the same results.
>
> anything useful from truss?
>
> ron
>
>
I should probably try that... but I've not had time to get back to it
yet...

[-- Attachment #2: Type: text/html, Size: 1359 bytes --]

Re: [9fans] plan9port: cocoa programmer needed

[andrey mirtchovski]

> anything useful from truss?

acid reports 'bad magic: unknown file type'. the app exits before any
of the standard osx instruments can record it.

here's the change to mkwsysrules.sh to build the cocoa devdraw by
default. i'm hoping with this my ./INSTALL will complete or exhibit
other errors.

-	echo 'WSYSOFILES=$WSYSOFILES osx-screen-carbon-objc.o osx-draw.o osx-srv.o'
+	echo 'WSYSOFILES=$WSYSOFILES cocoa-screen-objc.o osx-draw.o
cocoa-srv.o cocoa-thread.o'

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> could somebody put together a step-by-step on how
> to build for Lion?  I've downloaded the plan9ports
> tarball, extracted it to /usr/local/plan9, and
> done an hg pull -u, but INSTALL dies with
> complaints from ld about a malformed TOC entry in
> libbio.a.

John, this problem comes from Xcode 4.1.  If the
change to 9ar doesn't work for you (it doesn't for
me), try this hack:

	http://9fans.net/archive/2011/09/75

All should compile except Devdraw.  There are 3
versions of Devdraw in src/cmd/devdraw(!) The
default is the Carbon version: It doesn't work
anymore.  Then there is "devdraw-cocoa": an old
attempt.  Then there is my version, currently
called "cocoa", but it is the last week's release,
and I don't recommend to use it.  I recommend to
use the yesterday's release: it is not in the
official tree yet, but there is a patch here:

	http://codereview.appspot.com/5015042

Then you can do:

	mk cocoa && DEVDRAW=cocoa colors

But you cannot do:

	mk cocoa && DEVDRAW=cocoa acme

because, apparently, all that is based on
Libthread doesn't work.  If you do a small program
with 2 procs, a qlock, and some print(), you will
see that the output is very inconsistent.  Russ
recently said: "I am using Xcode 4.2 on Lion
without problems".  So it is maybe another Xcode
4.1 issue.

A solution is to use old binaries working on Snow Leopard, and then you can do:

	mk cocoa && DEVDRAW=cocoa acme

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> A solution is to use old binaries working on Snow
> Leopard, and then you can do:
>
>        mk cocoa && DEVDRAW=cocoa acme

For Acme, you should use a recent binary that Russ
kindly compiled on Snow Leopard:

	http://swtch.com/~rsc/acme

else Acme will not interpret "cmd+z" as "Undo" (a
command sent by Devdraw).

Re: [9fans] plan9port: cocoa programmer needed

[david jeannot]

> Can you guys perhaps create a small video about
> how you use your computers now?  It's difficult to
> understand for someone who doesn't own a mac, but
> I would still like to see what you're doing there ;)

I will not give you a video: I will make you want
to own a Mac.

I used Slackware for many years, and I loved to
run as root and to put $PLAN9 at the beginning of
$PATH directly in /etc/profile for example.  But
the last Slackware release came, and I got several
issues.  I had no courage to resolve them.  I
wanted some change.

As so many people seem to use Ubuntu, I finally
got curious.  The live CD give me a very favorable
impression, and I installed Ubuntu 11.04.  I used
it for almost 2 weeks.  But the more I used it,
the more I became convinced that all was only an
appearance, that all was indeed designed to make
you mad.  There is a strange duplicity in this OS,
and I shall not scruple to rename it "TMOS": The
Mask Of Sanity.

When I switched back to Slackware, I was so happy,
that I resolved all the issues in a few hours.
However my hard drive died soon after, and I had
to use Ubuntu again.

I developed such a repulsion that, without knowing
what I was doing, I bought a late 2010 MacBook Air
(11 inch), refurbished by Apple.  That was at the
end of June.

During two months before that date, I had
considered several times to buy a MacBook, but had
not the money for it.  I had read favorable
opinions about OS X on this list and, in the
meantime, my sister, who never understood how to
use Windows or Linux, was using OS X with ease.  I
was impressed by an OS that could satisfy both
professionals and amateurs.  I wasn't convince
though: there are so many people "fond of their
Mac" on the net; it seemed to me very irrational,
alike car tuning or case modding.

I sold all I could on Amazon and eBay to repay my
MacBook, and then I start using it.  I was first
amazed by say(1), the little tool that pronounce
any text.  (The voices are so real since OS X
Lion, that I don't feel lonely anymore.) Then I
needed a tool to write to the pasteboard, and a
few minutes later I found pbcopy(1).  Maybe there
is an equivalent on Linux, but I never dared to
look.  One week ago, I needed to sign a PDF file
made with troff(1).  I was previewing it with the
OS X application Preview, and I began to browse
the tools, maybe for a pen (I have an old graphics
tablet).  Suddenly I fall upon the tool
"Signature" who tells me to sign on a sheet of
paper and to place it in front of the camera.  I
was amazed, but not convinced: I thought it would
take a photo, that would contrast with the PDF's
background.  As soon as I placed the sheet of
paper in front of the camera, my signature was
vectorized on the screen!

Those are little things, but since I bought this
laptop, it's like that every day.  To be sure,
this OS is full of bugs, but upon the whole, it's
lovely.

I also found the Cocoa API very interesting to
learn.  Apple's documentation is good.


P.S.  To swipe from one Desktop space to another
(since OS X Lion) is as fun as it is useful, at
least on a 11-inch screen.

Re: [9fans] plan9port: cocoa programmer needed

[hiro]

> I will not give you a video: I will make you want
> to own a Mac.

If I had too much money I'd rather get me a secretary or not use
computers at all.

I'd like to see how you use acme with all that gesture stuff. Yeah, I
can read, but I don't understand the slang ;)