Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Is Mac OS X set_window_title() one of the cases that doesn't work?

Credits go to Peter Hull for helping out!
This thread is locked; no one can reply to it. rss feed Print
Is Mac OS X set_window_title() one of the cases that doesn't work?
Runesabre
Member #7,573
August 2006
avatar

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

_______________
Runesabre
Connecting People through Inspiring Interactive Entertainment
Enspira Online

Peter Hull
Member #1,136
March 2001

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
Member #7,573
August 2006
avatar

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

Thanks Peter!

_______________
Runesabre
Connecting People through Inspiring Interactive Entertainment
Enspira Online

Marcello
Member #1,860
January 2002
avatar

Your poor hamster. :'(

Marcello

Evert
Member #794
November 2000
avatar

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
Member #7,573
August 2006
avatar

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.

_______________
Runesabre
Connecting People through Inspiring Interactive Entertainment
Enspira Online

Evert
Member #794
November 2000
avatar

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
Member #1,136
March 2001

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
Member #794
November 2000
avatar

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? ;)

Go to: