Is Mac OS X set_window_title() one of the cases that doesn't work?
Runesabre

Mac OS X set_window_title() doesn't appear to set the window title. Is that a known issue?

Peter Hull

This code works OK for me, can you test and/or post code that doesn't work? (attached)

#include <allegro.h>

int main()
{
  allegro_init();
  install_keyboard();
  set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0,0);
  set_window_title("Matthew Leverton Ate My Hamster");
  readkey();
}
END_OF_MAIN()

Pete

Runesabre

I was calling set_window_title() before calling set_gfx_mode(). Moving the set_window_title() call after set_gfx_mode() works.

Thanks Peter!

Marcello

Your poor hamster. :'(

Marcello

Evert
Quote:

I was calling set_window_title() before calling set_gfx_mode(). Moving the set_window_title() call after set_gfx_mode() works.

The documentation doesn't specify an order for calling these in; should this be documented?
The documentation does say that "... this routine alters the window title for your Allegro program," weakly suggesting that the window should exist at that point, but it's not explicit.
How do other platforms behave?

Runesabre

When I had set_window_title() called before set_gfx_mode(), Windows and Linux windows showed the proper window title while Mac did not.

Personally, and if it's even possible, I prefer not to have an order requirement. Otherwise, a documentation note would be nice.

Not a big deal either way, I'm just glad it works thanks to Peter's help.

Evert

Ok, I'll see if I can look into it before releasing 4.2.1
I think I'm going to take the stance that since no such requirement is mentioned in the docs and neither the Windows nor the X11 port require it, this is a bug in the MacOS X port. It shouldn't be that hard to fix either.

Peter Hull

It's already been thought of, apart from there's a bug. It works like this:
install_allegro sets the default title (I hope no-one is expecting it to work if called before install_allegro?)

The implementation of set_window_title copies the supplied title into the variable osx_window_title, and does the OS call to actually set the title if the window exists.

1/* osx_sys_set_window_title:
2 * Sets the title for both the application menu and the window if present.
3 */
4static void osx_sys_set_window_title(AL_CONST char *title)
5{
6 char tmp[ALLEGRO_MESSAGE_SIZE];
7
8 _al_sane_strncpy(osx_window_title, title, ALLEGRO_MESSAGE_SIZE);
9 do_uconvert(title, U_CURRENT, tmp, U_UTF8, ALLEGRO_MESSAGE_SIZE);
10 
11 NSString *ns_title = [NSString stringWithUTF8String: tmp];
12
13 if (osx_window)
14 [osx_window setTitle: ns_title];
15}

In set_gfx_mode, when the window is created, the call
set_window_title(osx_window_title)
is made. This should set the title to whatever has been set previously (which is the default if set_window_title has never been called by the user). This is the desired behaviour. Unfortunately, _al_sane_strcpy fails if source == destination, which it is, in this case. It leaves osx_window_title as an empty string, which is probably what you are seeing.

Still following me?

So I propose an explicit check for this case,

Index: src/macosx/system.m
===================================================================
--- src/macosx/system.m (revision 7527)
+++ src/macosx/system.m (working copy)
@@ -563,7 +563,8 @@
 {
    char tmp[ALLEGRO_MESSAGE_SIZE];
    
-   _al_sane_strncpy(osx_window_title, title, ALLEGRO_MESSAGE_SIZE);
+   if (osx_window_title != title)
+       _al_sane_strncpy(osx_window_title, title, ALLEGRO_MESSAGE_SIZE);
    do_uconvert(title, U_CURRENT, tmp, U_UTF8, ALLEGRO_MESSAGE_SIZE);
 
    NSString *ns_title = [NSString stringWithUTF8String: tmp];

This is IMO the lowest impact solution, though probably not the neatest one.
(diff attached)

Pete

ps. AFAIK, the behaviour of strncpy is supposed to be undefined if source and destination overlap (link) so the behaviour of _al_sane_strncpy seems quite reasonable in this case.

Evert
Quote:

This is IMO the lowest impact solution, though probably not the neatest one.
(diff attached)

A single line comment describing what's going on might be nice, though I would probably change _al_sane_strncpy to leave the case source==destination alone.

Quote:

ps. AFAIK, the behaviour of strncpy is supposed to be undefined if source and destination overlap (link [opengroup.org]) so the behaviour of _al_sane_strncpy seems quite reasonable in this case.

My manpage actually says something a bit stronger than that:

Quote:

The strings may not overlap

Still, it's called _al_sane_strncpy for a reason, right? ;)

Thread #587424. Printed from Allegro.cc