OSX REBOL/VIEW NOTES

Version anglaise:

To allow a maximum of people to participated to the implementation of a port/adaptation to Mac OS X of the REBOL/VIEW VM, I have created this article as a medium between a maximum of people and the discussion group on altme. Every one is free to participate this article works like a chat.

First part is the yet posted to altme discussions.

The second part is your participation. I, Shadwolf, will post all the content in the second part of this page to the altme private group OSX IMP and post here the response.

The third part is a little resume of the discussion content in french to allow people to have a quick view on the discussion.

Version Francaise:

Afin qu’un maximum de personnes puissent participer à l’implémentation du portage/adaptation à MacOSX de la machine virtuelle REBOL/VIEW, j’ai créé cet article comme un intermédiaire entre un maximum de personnes et le groupe de discussion sur AltMe. chaque personne est libre de participer, cet article marche comme un “chat”.

La première partie présente le contenu du groupe de discussion privé OSX imp sur AltME.

La deuxième partie est destinée a recevoir vos contributions. Moi, Shadwolf, posterai tout son contenu sur le groupe altme et afficherai ici dans la première partie les réponses.

La troisième partie est un résumé rapide de la discussion afin que tout le monde puisse avoir rapidement un apperçu des échanges.

---

(Here are the content of the discution on OSX imp private group) Jour1:*

Carl <19/04/05 23:10(GTM+1)>: Project created for REBOL/View OS X implementation details. Info note: REBOL for OS X is Carbon based. Anyway, back to Interface builder. It’s been years since I’ve run any of this kind of stuff on mac…. so getting adjust back to it. Oh…. so these nibs that get saved are XML, eh?

JaimeVargas <19/04/05 23:15 >: Carl I think the answer maybe in writting a wrapper for the function objc_msgSend. This will send a msg to a particular object in the cocoa class three. It can instantiate an new object and then tell him to execute and return something. I am reading more…

Carl <19/04/05 23:17(GTM+1)>: I hould mention something really important: REBOL cannot use the standard event loop - because REBOL has async port and other actions that are happening at the same time.

So, the main loop of REBOL uses ReceiveNextEvent(). It will be problematic if we have to “turn over” control to the GUI for any length of time, because that means we’ll miss our async port io.

JaimeVargas <19/04/2005 23:20 (GTM+1): Humm. Interesting. So ReceiveNextEvent is from carbon ins’t it? /usr/bin/rebcmd -sq smart-agent-do.r ;this is what I am running. /usr/bin/rebcmd REBOL/Command 2.5.8.9.2

Carl <19/04/2005 23:23> yes, RNE is carbon. I guess the main thing will be how to handle these nibs and xibs in carbon world.

JaimeVArgas <19/04/2005 23:28> Carl I don’t want to be pushy, but I think as a short term plan compilin the X11 src should be faster. A lot faster.

Carl <19/04/2005 23:29> Really??

JaimeVargas <19/04/2005 23:29> Later on you can try to do Cocoa. Because other wise you will be living in between worlds cocoa/carbon. Which is possible but maybe more conversome.

Carl <19/04/2005 23:29> I’m not sure how X11 will solve many of the problems that we have to deal with on Mac.

JaimeVargas <19/04/2005 23:29> Well, OSX has full X11 support, and your code is mainly bsd. Why not just compile the sources.

Carl <19/04/2005 23:30> Ok, will give that a try. Time for lunch, then when I get back, I’ll see what happens.

JaimeVargas <19/04/2005 23:30> But X11 will give you an App in the market maybe in two weeks or less. Then you can push for more compatibility and enhancements. Do you have Xcode Tools?

Carl <19/04/2005 23:33> Wait a min…. I don’t see any X stuff running. There is no XSF process alive.

JaimeVargas <19/04/2005 23:33> You need the X11 http://www.apple.com/macosx/features/x11/ You first start the environment it should be an application in yous Applications folder /Applications/Utilities folder If not ther you will need to install it. Not that difficult just download and install.

Carl <19/04/2005 23:38> Ah…. I’ve never heard the words X11 and “not that difficult” in the same sentence before. ;) Lunch time.

Jaime Vargas <19/04/2005 23:38> Hahaha. Well I am crossing my fingers. Because the API should be the same. A lot of good X11 applications have already been ported.

Will <19/04/2005 11:46> And in 2 weeks you can get Tiget aka 10.4 with all new Xcode 2.0 http://developer.apple.com/macosx/tiger/xcode2.html When installing developer tools you need to check the x11 sdk, right Jaime?

JaimeVargas <19/04/2005 23:48> Correct. Otherwise it doesn’t install the required headers. But I am not sure Carl is using Xcode tools.

Carl <20/04/2005 00:17> Back. Here is a simple question: does X11 run on all OS X macs?

JaimeVargas <20/04/2005 00:30> Yes. Since jaguar.

Will <20/04/2005 00:32> aka 10.2

JaimeVargas <20/04/2005 00:33> There are some 3rd party implemetations for OSX 10.1, but I believe most people is on Jaguar or Panther. That is 10.2 and 10.3

JaimeVargas <20/04/2005 00:41> And a lot will be moving to Tiger 10.4

Shadwolf <20/04/2005 00:49> Using X11 implementation seems to be good but wan’t it to difficult to use in the same time than other standard applications. I think if people have to use another window management system and install it in plus of the default one they can find this wierd and this could be a brake to OSX diffusion…Example I want to use a non X11 navigator or a photoshop and I want to use at the same time a rebol app switching betwin OSX basic window management and X11 could be very bad blocant issue. In front of having both on the same window manager.

JaimeVargas <20/04/2005 00:53> Shadowolf. X11 apps in OSX behave like normal Apps. There is no distinction in OSX. They share same clipboards, drag-and-drop features, fonts, etc. They just are coded with a different API than Cocoa, and it maybe the fastest path to have Rebol/View in OSX. I bet in two weeks. Native App will take more time because a lot functionality needs to be written to the proper API either carbon or cocoa. RT already has a source based in X11, so porting should be straight forward. That source is what is used for linux, openbsd, etc.

Shadwolf <20/04/2005 00:57> so X11 on OSX is more like a link betwin cocoa window manager and X11 coded apps like xcalc xterm xbill etc… This allow OSX to use a yet hudge gnu/X11 sofware library ?

JaimeVargas <20/04/2005 00:57> Exactly. Thats ther reason you see a lot of open source developers switching to Macs.

Shadwolf <20/04/2005 00:59> hehehe clever guys ;)

JaimeVargas <20/04/2005 01:02> Actualy X11 and Cocoa run on top of Quartz the gfx foundation for OSX.

Shadwolf <20/04/2005 01:05> ok I think Francois jouen on french scene try to run the rebol/view based on X11 on a MacOSX with a X11 server installed on it but he doesn’t succed to have it running maybe (surely) because of the binary difference.

Shadwolf <20/04/2005 01:08> maybe the only fact to recompile using a macOSX adapted gcc of the REBOL/VIEW sources for BSD os could yet leads to a working version ?

JaimeVargas <20/04/2005 01:10> Which rebol/view for X11?

Shadwolf <20/04/2005 01:11> yes

JaimeVargas <20/04/2005 1:12> There is no compatibility layer in OSX for binaries of other bsd operating systems.

Shadwolf <20/04/2005 01:12> yes I know that’s why as Francois Jouen doesn’t have the sources he wasn’t able to have a runable version of REBOL/View on his MACOSX + X11 .)

JaimeVargas <20/04/2005 1:13> Porting the X11 version should work. As far as I know Calr is going to try this. I guess if he doesn’t succeed quickly. He will probably continue on the native track. Which I hope doesn’t take to long.

Jour2:

Carl <22/04/2005 17:11>: Ok… so REBOL is running now in OS X, and able to open windows and display graphics, etc… But, it is time to figure out the rest of the OSX “wrappers” that will be required to make REBOL a mac-friendly app. I have some questions, and could use some help on this part, since it is really more “boilerplate” type stuff.

1. Is there some way that I can build the app from Makefiles, rather than using Project Builder or Xcode? (The reason for that is simple: we like to be able to build new versions of REBOL remotely without user-interaction being required.)

2. What’s the best way to get the program icon and property list built for the executable?

3. Once I have the nib files for the menus, what’s the best way to include those into the program?

JaimeVargas <22/04/2005 17:16 >: 2. If it is an OSX application you should have a Folder inside that there is a Resources folder thats where the icons go.

Carl <22/04/2005 17:17>: Right now it is simply a BSD executable file created by gcc. In other words, I’m building it the same way I build REBOL on all platforms – with a makefile that uses GCC.

JaimeVargas <22/04/2005 17:18>: Humm. Are you using the latest Xcode tools?

Carl <22/04/2005 17:19>: No tools. Just gcc. BTW, did you see my question #1 above?

JaimeVargas <22/04/2005 17:21>: Yes. I am confused by it. Because I understand you are building this with GCC so you already have make files

Carl <22/04/2005 17:21>: Yes, to clarify:

JaimeVargas <22/04/2005 17:21> So I am not sure what you need Project Builder or Xcode for.

Carl <22/04/2005 17:22>: REBOL uses a standard build process that creates its own makefile… That works fine and it is producing an executable that runs. But… I want to now add the menus for it… The other thing, and this is really a problem: The windows created by REBOL never seem to become “active” (they never get the OS focus). Even if my code calls SelectWindow() it does not become active. My assumption is that because I do not have any menus, the OS will not allow the windows to activate.

JaimeVargas <22/04/2005 17:26> Humm thats a hard one. Becuase there are other applications in OSX without menus and they get the system focus. Specially small system utilities. I am looking on how to add menus to a bsd tool.

Carl <22/04/2005 17:29> I should note: I am just *assuming* that this is the reason. If we can find a way to make the window focus work w/o menus, I can problably send you a copy of REBOL/View today or tomorrow to try out!

JaimeVargas <22/04/2005 17:30>: How are you creating the window?

Carl <22/04/2005 17:31>: CreateNewWindow() Then I do a SelectWindow(). Here is another possibility for the problem: I’m running REBOL from the shell. That means that my print statements are shown in the shell window. Perhaps in writing to the shell window, I am throwing the focus back to that window, removing it from my own. If so, that would be unusual – most Unix systems do not move the focus simply due to output. I will comment out my C-level print statements and see if that keeps my focus.

JaimeVargas <22/04/2005 17:38>: I don’t think thats the reason.

Carl <22/04/2005 17:42> Yes. Removed the print. Still has the problem. I’m just going to build a simple menu in C and call DrawMenuBar() on it to see if that works.

JaimeVargas <22/04/2005 17:55>: Carl this example shows you how to use Nib files from the Carbon API http://developer.apple.com/samplecode/Converter_nib/Converter_nib.html

Carl <22/04/2005 17:55>: That will probably come in handy. So, I’ve created a menu, and then called DrawMenuBar(). Running it… I still get no focus…. but I get no menu bar either. I still see the Terminal menu bar. <frustrated> <flame>I think it’s stuff like this that keeps more people from porting apps to the Mac.</flame>

JaimeVargas <22/04/2005 18:04>: I think carbon is the most difficult path, unless you already did have a carbon app before OSX came into existance.

Carl <22/04/2005 18:04>: Goggling… I find this: http://www.mymac.ws/mac-opening-another-window-from-a-tool-help-3109.html BTW, Cindy walked in… She says “hello”.

JaimeVargas <22/04/2005 18:06>: Thx. Give her my regards.

Carl <22/04/2005 18:08>: I have a bunch of OS9 code that I’ve used here and there for making the Carbon easier. (The OS9 version of REBOL.) The thing is… OSX Carbon has new functions… so I try to use those where possible. Things like ReceiveNextEvent, etc. It’s all working fine other than this Window selection problem.

JaimeVargas <22/04/2005 18:09>: Have you run carbon dater on the OS9 application?

Carl <22/04/2005 18:10>: No.

JaimeVargas <22/04/2005 18:10>: That may tell you what to remove.

Carl <22/04/2005 18:10>: I wish there had been a reply to that above URL.

JaimeVargas <22/04/2005 18:10>: While keeping the application usable.

Carl <22/04/2005 18:11>: I need to keep my focus on the selectwindow problem right now…. still searching the web…

JaimeVargas <22/04/2005 18:13>: So you will need to carbonize the OS9 application first, this will give you all the gfx you got working for OS9 in OSX, without emulation. Then you can change the core. This is the path others developer of “Mac classic applications” followed. But I will keep looking on selecting the window first.

Carl <22/04/2005 18:16>: Note: I am not using the OS9 stuff at all currently. The first bit I used was the menu test above.

JaimeVargas <22/04/2005 18:17>: Ok. Researching “focus” problem on this side.

Carl <22/04/2005 18:17> thanks - I’m going to grab a bite… back in a bit.

JaimeVargas <22/04/2005 18:19>: http://developer.apple.com/samplecode/MoreIsBetter/MoreIsBetter.html A code sample and library which provides indispensable work-arounds and illustrations for Mac OS programming. Wrapper functions for: Control Manager, Appearance Manager, Dialog Manager, Window Manager, Menu Manager, Navigation Services, and many more. Requires: Mac OS X 10.2.x with Dec 2002 Developer Tools, or CodeWarrior 8.3 Keywords: high level, toolbox, hltb, MoreFiles, MoreIsBetter, glue, wrapper, library code Maybe this will give you some clues.

#include "CarbonCode.h"
#include <Carbon/Carbon.h>

void InitializeCarbon()
{
  EventRecord	dummyVariable;

  /* Here we call wait next event once.  This is just to stop the dock icon bouncing...
   * Otherwise since this is not a typical application it keeps bouncing for quite some time
   * (until you put up a dialog).
   * First Argument: The type of event to get.  Here any event is fine.
   * Second Argument: This is where the information on the even will be returned.  Here we actually
   *   disregard whatever event we got (hopefully there was no event).
   * Third Argument: The wait time before returning automatically from WaitNextEvent.  Here we pass
   *   zero since we want to remove instantly.
   * Forth Argument: A variable to return mouse information.  Here we don't care so pass NULL.
   * Return Value: A boolean indicating if we got an event or not.  Again we don't care so pass NULL.
   */
  (void)WaitNextEvent(everyEvent,&dummyVariable,0,nil);
}

void DisplayDialogFromCarbon(const char* HeaderStringToDisplay, const char*  MessageToDisplay)
{
  SInt16 outSelection;
  Str255 messageToDisplayPascal = "\p";
  Str255 headerStringToDisplayPascal = "\p";
  ProcessSerialNumber ourPSN;
  OSStatus error;
  
  //If we were passed a string convert it to a pascal string for use in the dialog
  if (HeaderStringToDisplay != NULL)
      {CopyCStringToPascal(HeaderStringToDisplay, headerStringToDisplayPascal);}
  
  if (MessageToDisplay != NULL)
      {CopyCStringToPascal(MessageToDisplay, messageToDisplayPascal);}
  
  /* Here we will set the MacOSX native section of the process to the foreground for putting up this
   * dialog box.  First step is to get our process serial number.  We do this by calling 
   * GetCurrentProcess. 
   * First Argument: On success this PSN will be our PSN on return.
   * Return Value: A Macintosh error indicating success or failure.
   */
  error = GetCurrentProcess(&ourPSN);
  
  //If no error then set this process to be frontmost.
  if (error == noErr)
  {
      /* Calling SetFrontProcess to make us frontmost.
       * First Argument: The Process Serial Number of the process we want to make frontmost.  Here
       *    of course we pass our process serial number
       * Return Value: An error value indicating success or failure.  We just ignore the return
       *    value here.
       */
      (void)SetFrontProcess(&ourPSN);
  }

  /* Displaying standard alert dialog from Carbon
   * First Argument: Alert type, here we want a not alert.
   * Second Argument: The header of the alert panel.  Here we use the string passed to us.
   * Third Argument: The message in the alert panel.  Again we use the string passed to us.
   * Forth Argument: A structure for customizing the alert.  Here we don't want anything fancy
   *    so just pass NULL.
   * Fifth Argument: The selection of the user within the dialog.  Here we are passing a dummy
   *    variable we don't use.
   */
  (void)StandardAlert(kAlertNoteAlert, headerStringToDisplayPascal, messageToDisplayPascal, 
                      NULL, &outSelection);
}

void BeepFromCarbon()
{
  //Do simple system beep
  SysBeep(1);
}

I think GetCurrentProcess and SetFrontProcess is what you are looking for.

Carl <22/04/2005 18:35>: back SetFrontProcess – hey, that’s a new one…. checking… Bus error. Trying another variation…. No bus error this time, but did not work either. Bus error was caused by error in the OS X doc for SetFrontProcess. Says can use kCurrentProcess for PSN. They lie. I verified that I was getting a valid PSN to pass. But still did not work. This is a process scheduling function – but it was worth a try.

JaimeVargas <22/04/2005 18:50>: I tried the above example in my machine at it works. The full example is here. http://developer.apple.com/samplecode/X11CallCarbonAndCocoa/X11CallCarbonAndCocoa.html Maybe you need to link to anohter library. From what I see you need to be linking to Carbon.framework and CoreFoundation.framework

Carl <22/04/2005 18:55> But, if I’m not linked to Carbon, why would my window even come up at all?

JaimeVargas <22/04/2005 18:56>: Which libraries are you linking to?

Carl <22/04/2005 18:57>: /system/library/frameworks/carbon.framework/carbon

JaimeVargas <22/04/2005 18:58>: SO you are link to Carbon. Are you link to CoreFoundation?

Carl <22/04/2005 18:59> No explicitly. But, there are no link errors.

JaimeVargas <22/04/2005 19:00> I still don’t understand why you don’t get the focus. The example above works. Maybe carbon is not being initialized in your application.

Carl <22/04/2005 19:03>: Is there something special I need to do at the start of my code? I can probably trim all this down to a half page example – and try that. Then, you can try it there too.

JaimeVargas <22/04/2005 19:05>: InitializeCarbon Before gettiing the GetCurrentProcess

Carl <22/04/2005 19:07>: That function is not part of the Carbon API – from what I can tell here.

JaimeVargas <22/04/2005 19:07>: InitializeCarbon should be the first line in main after type declarations. GetCurrentProcess may be define in CoreFoundation. Is documented here. http://developer.apple.com/documentation/Carbon/Reference/Process_Manager/prmref_main/chapter_5.2_section_2.html And in the cross reference in XCode.

Carl <22/04/2005 19:10>: Yes, that’s the doc I used to implement it. InitializeCarbon is not a Carbon function.

JaimeVargas <22/04/2005 19:11>: No it is not is wrapper function look at the code above. It wraps this line (void)WaitNextEvent(everyEvent,&dummyVariable,0,nil); Which is kind of stupid. But worth a try.

Carl <22/04/2005 19:15>: Just a min… writing a short program that shows the problem. Then I can send you the source to try there.

My little test program shows the problem.

I will post it in just a min.

www.rebol.net/notes/osx-window-problem.html

There it is!

Takes just a few seconds to try. Just copy the line at the top to compile it.

JaimeVargas <22/04/2005 20:37> Back. I will test and report back. Carl I am getting events from the window.

Carl <22/04/2005 20:37> Yes, but is the window in the front?

JaimeVargas <22/04/2005 20:42> Besides I ma alive. From clickin on the front window. Example I’m alive. I’m alive. Event: Class cgs Kind 13 Event: Class mous Kind 1 Event: Class mous Kind 2 Event: Class cgs Kind 13 Event: Class mous Kind 1 Event: Class mous Kind 2 I’m alive.

Carl <22/04/2005 20:44> That is normal.

Is the drag bar at the top slightly transparent?

If so, then the window is not the focus.

Try typing on the keyboard. Do you see events?

btw, see my blog link above – explains it

JaimeVargas <22/04/2005 20:45> Only mouse events.

Carl <22/04/2005 20:48> yes. Updated blog. SetUserFocusWindow does not fix the problem either.

JaimeVargas <22/04/2005 20:52> I wonder who is the parent of the window. When I try to type on top of the window the chars show up in the terminal but no event is generated. This can be result of the lack of focus on the window.

Carl <22/04/2005 21:08> I posted question to rebol list too.

See http://www.rebol.net/article/0157.html

JaimeVargas <22/04/2005 22:28> Carl if you create a carbon project in X-Code and replace the template with your code. You will notice that the application process all kinds of events. Including keyboard events.

If you want to see the menus working and the window responding to events use the standard RunApplicationEventLoop() instead of your own eventloop.

This is the code I have use to test.

#include <Carbon/Carbon.h>

main()
{
      WindowRef window;
      Rect bounds;
      WindowClass class = kDocumentWindowClass;;
      WindowAttributes attributes = kWindowStandardDocumentAttributes;
      EventRef event;
      EventTargetRef wintarget;
      int str[2];
      ProcessSerialNumber ourPSN;
      OSStatus error;

FILE *fp = fopen("/tmp/test.log","w");

      fprintf(fp, "Testing... Click in window. Press CTRL-C to quit.\n");

      SetRect(&bounds, 100, 100, 500, 500);
      if (CreateNewWindow(class, attributes, &bounds, &window) != noErr) {
              printf("Window will not open\n");
              exit(0);
      }
      wintarget = GetWindowEventTarget(window);
      InstallStandardEventHandler(wintarget);

      ShowWindow(window);

      /* error = GetCurrentProcess(&ourPSN);
       if (error == noErr) {
              (void)SetFrontProcess(&ourPSN);
      }
*/

      ShowWindow(window);

      // Line below can also be used... but has same problem.
      // RunApplicationEventLoop();

      str[1] = 0;
      while (true) {
              if (ReceiveNextEvent(0, NULL, kEventDurationSecond, true, &event) == noErr) {
                      str[0] = GetEventClass(event);
                      fprintf(fp, "Event: Class %s Kind %d\n", str, GetEventKind(event));
              } else
                      fprintf(fp, "I'm alive.\n");
      }
}

This is a segment of /tmp/test.log

I’m alive. … Event: Class appl Kind 1 Event: Class appl Kind 111 Event: Class eppc Kind 1 Event: Class appl Kind 103 Event: Class mous Kind 5 … Event: Class cgs Kind 14 Event: Class mous Kind 1 Event: Class cgs Kind 14 Event: Class mous Kind 2 Event: Class cgs Kind 14 Event: Class mous Kind 1 Event: Class cgs Kind 14 Event: Class mous Kind 2 Event: Class mous Kind 5 … Event: Class cgs Kind 14 Event: Class mous Kind 1 Event: Class mous Kind 6 … Event: Class cgs Kind 14 Event: Class mous Kind 2 Event: Class mous Kind 5 … Event: Class cgs Kind 14 Event: Class mous Kind 1 Event: Class mous Kind 6 Event: Class cgs Kind 14 Event: Class mous Kind 2 Event: Class mous Kind 5 … Event: Class keyb Kind 1 Event: Class keyb Kind 3 Event: Class keyb Kind 1 Event: Class keyb Kind 3 Event: Class keyb Kind 1 Event: Class keyb Kind 3 Event: Class keyb Kind 1 Event: Class keyb Kind 3 Event: Class mous Kind 5 … Event: Class cgs Kind 14 Event: Class appl Kind 2 Event: Class appl Kind 111

As you can see all kinds of events are gather. [mous keyb cgs appl eppc]

Because the events are no event handlers and you don’t see the window moving or resizing. If you need that you need to use the RunApplicationEventLoop which installs default handlers for some events like menu handling, window draggin, etc.

Carbon Events Versus WaitNextEvent. If you are writing a new Carbon application, you should use the Carbon Event Manager. http://developer.apple.com/documentation/Carbon/Conceptual/Carbon_Event_Manager/Concept/chapter_17_section_4.html

Carl <22/04/2005 11:33> Ok…. some replies:

On RunApplicationEventLoop: this is a poor design on OS X because it does not deal with the Select function that handles sockets and other IO. In other words, to all but the simplest of programs, that design is not useful.

(I’ve read all those chapters many times.)

JaimeVargas <22/04/2005 11:35> The you need to move the CFEventLoop.

Carl <22/04/2005 11:35> The ReceiveNextEvent method appears to be the only valid approach. WaitNextEvent and GetNextEvent are also allowed, but are watered down versions.

The perfect design would be to integrate SELECT with the event loop… but there is ONLY ONE computer I know of that did that: Amiga.

Regarding Xcode: is that necessary? Shouldn’t it be possible to the the exact same thing from the gcc compiler?

JaimeVargas <22/04/2005 11:39> This is what you want. A CFRunLoop object monitors sources of input to a task and dispatches control when they become ready for processing. Examples of input sources might include user input devices, network connections, periodic or time-delayed events, and asynchronous callbacks.

http://developer.apple.com/documentation/CoreFoundation/Reference/CFRunLoopRef/index.html

Carl <22/04/2005 11:40> That sounds more promising…. checking the link

JaimeVargas <22/04/2005 11:40> Regarding Xcode. The short answer is yes, unfortunately I don’t know all the flags and switches involved.

Maybe after observice xcodebuild console output for a while we can make the guess of what is needed.

Carl <22/04/2005 11:41> I looked at CFRunLoop earlier today – but it was not clear to me how to use it. Looking at it again right now, it’s still not clear to me.

With regard to builds: there are something like 50 files that are part of a normal REBOL make. It would be good to not have to deal with these separately on OSX – otherwise builds for OS X will get lower priority.

Reading CFRunLoop one more time – I don’t see any value in this approach for REBOL. This runloop concept in OS X adds a lot of complexity for little value, and does not appear to solve the basic problem related to Select.

JaimeVargas <22/04/2005 11:56> I am not sure what is the problem.

Carl <22/04/2005 11:57> Are you familiar with the Posix select() function?

JaimeVargas <22/04/2005 11:57> Perhaps the X11 route is the easiest in that case.

Carl <22/04/2005 11:57> http://linux.com.hk/PenguinWeb/manpage.jsp?name=select&section=2

JaimeVargas <22/04/2005 11:58> Do you have such a function on Windows API?

Carl <22/04/2005 11:58> Yes. And so does OS X - it is used right now on Core and Base, etc.

Select will wait until IO occurs on network sockets (and other IO devices).

But, if the GUI code also needs to do a wait, then you have a problem… because if you wait in Select, the GUI goes dead. If you wait on the GUI, then all your sockets go dead.

For simple programs, it’s not a problem, because the user is willing to wait until the IO has finished…. but in REBOL, that would freeze all your buttons, and even the ESCAPE in the console

It is possible to deal with this problem with threads, but to do that would create a whole new set of problems within the current implementation.

JaimeVargas <23/04/2004 00:01> But there must be a solution. Maybe not a unified GUI-select. Just a different approach. I wonder how the X11 apps the work without freezing

Carl <23/04/2005 00:02> I think what I’m doing right now will work fine. It is a pretty good solution.

I also glanced on the net and noticed that TCP and Python use a similar approach to my own.

Along a different line….

JaimeVargas <23/04/2004 00:03> Why CFRunLoop doesn’t help you. In theory it does what you want, catch all kinds of envents and dispach handlers accordingly.

Carl <23/04/2005 00:02> Because CFRunLoop is not integrated wth Select function.

It is possible that Select is implemented with the CFRunLoop functions at a very low level…. but finding that source code may be difficult.

And, doing it w/o source code would probably take a couple months.

So… regarding window activation – I have another idea… testing it now.

JaimeVargas <23/04/2004 00:05> Yes. So what approach do you plan to follow. The tricks I mentioned above gets you the gui events.

Carl <23/04/2005 00:07> In the old OS9 code, you called functions like InitWindows, InitFonts, InitMenus, etc…. to get everything setup. I’m wondering if there is a function like that that I am missing. Sort of like that InitCarbon thing you mentioned.

In OSX, those are all unsupported functions… but perhaps there is one that is required… somewhere

JaimeVargas <23/04/2004 00:08> I don’t see it in the documentation. It is a lot simpler to just create the project in XCode.

Carl <23/04/2005 00:09> You can say that, because you don’t have to try to port REBOL to XCode!

So, here is a critical question for you about XCode:

JaimeVargas <23/04/2004 00:10> I am just trying to help

Carl <23/04/2005 7:01> Quick status report: got R ported into ProjectBuilder and it worked. After that, continued to work on various event handlers.

It is possible that I might have something to send out later this weekend…. if all goes well.

---

(Post here what you want me to relay to OSX IMP group)

---

Sur les conseils de Jaime Vargas, Carl Sassenrath s’achemine vers une version X11 du code de REBOL/View. Ainsi pour pouvoir utiliser REBOL/View sous MACOSX il faudra si l’idée est concrétisée par une version concluante installer le serveur X11 pour MACOSX.

Carl a fini le portage de REBOL/View sur MacOSX mais il reste quelques problèmes qu’il n’arrive pas a solutionner. Aidé par Jaime Vargas il recherche les solutions à ces problèmes.