GTK+ Mac OS X state of the union
Hello, For the last three months I've been working on making the GTK+ Mac OS X port in a somewhat feature-complete state so we can slap a "1.0" tag on it. The progress (as well as the remaining items) can be found on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Roadmap The most challenging task remaining now is to make GTK+ use the built-in double-buffering features that exist in Mac OS X; I have sort of an idea on how to do this and I'll send off a proposal shortly to the list, since this most certainly changes some of the low-level parts of GDK) We at Imendio always welcome help, there's a list of things to do availabe on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do with varying degrees of difficulty. Regards, Anders ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Andres, Il giorno 28/mar/06, alle ore 09:56, Anders Carlsson ha scritto: Hello, For the last three months I've been working on making the GTK+ Mac OS X port in a somewhat feature-complete state so we can slap a "1.0" tag on it. The progress (as well as the remaining items) can be found on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Roadmap I am eager to have a native Gtk+ port on Mac Os X because I hate the poor level of integration of OpenOffice and other Gtk based tools on Mac. So I want to thank you for your work. The most challenging task remaining now is to make GTK+ use the built-in double-buffering features that exist in Mac OS X; I have sort of an idea on how to do this and I'll send off a proposal shortly to the list, since this most certainly changes some of the low-level parts of GDK) We at Imendio always welcome help, there's a list of things to do availabe on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do with varying degrees of difficulty. I considered to see wether I could help with this work. I do not write code that frequently, but I hoped I could be useful... I managed to install the Gtk machinery on my ibok. I installed all the tools in the reuired version, and then all the libraries, one by one... Now the point is that I have a really impressive bunch of code on my machine ! Pango, Cairo, atk, Gtk... wow ! I don't understand all this code ! Who does call who, when ? What's the intended model ? How am I supposed to flip inside the framework ? Is there any class diagram or collaboration diagram or any other kind of diagram ? I considered Eclipse with the c++ module but it crashes :-( I considered some Emacs based tools but learning Emacs is something that could be more demanding than porting the whole thing perfectly How do you use to deal with this problem ? Does it at least seems reasonful to you or you just don't feel it ? Thanks so much Bye Catonano ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Anders Carlsson wrote: Hello, For the last three months I've been working on making the GTK+ Mac OS X port in a somewhat feature-complete state so we can slap a "1.0" tag on it. The progress (as well as the remaining items) can be found on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Roadmap The most challenging task remaining now is to make GTK+ use the built-in double-buffering features that exist in Mac OS X; I have sort of an idea on how to do this and I'll send off a proposal shortly to the list, since this most certainly changes some of the low-level parts of GDK) We at Imendio always welcome help, there's a list of things to do availabe on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do with varying degrees of difficulty. Looking good so far; I just got it all compiled. gtk-demo runs, though with a bunch of visual glitches (BG of many windows is black, BG of parts of scrollbars is black, etc.). If I have some more time, I'd love to try and tackle a few items on the TODO list. I have a question though about menu bars. I'm sure this is a bit tricky to handle, but might there be a way to designate that a particular GtkMenuBar attached to a particular window is the "main" menubar, and somehow merge its contents into the OS X top-of-screen menubar? I'm a little stumped as to the best way to do this, since technically you can pack as many menubars as you want into a single window. Thoughts? -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Anders Carlsson wrote: We at Imendio always welcome help, there's a list of things to do availabe on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do with varying degrees of difficulty. In an unidirectional way? Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Ter, 2006-03-28 at 11:22 +0200, Adriano wrote: [...] > I am eager to have a native Gtk+ port on Mac Os X because I hate the > poor level of integration of OpenOffice and other Gtk based tools on > Mac. Just nitpicking here, but OpenOffice is not Gtk based. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, 2006-03-28 at 03:46 -0800, Brian J. Tarricone wrote: > Looking good so far; I just got it all compiled. gtk-demo runs, though > with a bunch of visual glitches (BG of many windows is black, BG of > parts of scrollbars is black, etc.). If I have some more time, I'd love > to try and tackle a few items on the TODO list. > > I have a question though about menu bars. I'm sure this is a bit tricky > to handle, but might there be a way to designate that a particular > GtkMenuBar attached to a particular window is the "main" menubar, and > somehow merge its contents into the OS X top-of-screen menubar? I'm a > little stumped as to the best way to do this, since technically you can > pack as many menubars as you want into a single window. Thoughts? Yup this indeed a stickler. Given the current hodge-podge of menu creating routines, plus the fact that menus are abstract in GTK (pop-up menus, menubars, etc) doing this in an automated way seems to be very difficult. I would be in favor of adding an API that could take a GtkMenu tree object and stick it up on the OS X menu bar. This way GTK apps could be modified as needed by the developer to better support OS X, rather than try to make it automatic. A program like the Gimp, for example, would pose a real problem to automatically trying to manipulate the OS X menubar. Which menu do you display? The one on the main window, the one on the image window? The developer usually has a good idea of how to deal with that, so providing a simple API for that might be the best way to go. Of course doing it in such a way that the final code need not be changed between platforms would still be a challenge. Michael > > -brian > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On 3/28/06, Michael L Torrie <[EMAIL PROTECTED]> wrote: > [snip] > Of course doing it in such a way that the final > code need not be changed between platforms would still be a challenge. > > Michael Wouldn't be that hard, the function just wouldn't do anything on other platforms. -- Travis Watkins http://www.realistanew.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, 2006-03-28 at 11:44 -0500, John Ehresman wrote: > A separate api is probably needed. OS X applications can and should > display menu bars when no top-level windows are open. Also the > preferences, quit, and possibly other items should be on the menu with > the applications name on it instead of the file menu. Since preferences and even quit could be anywhere, the app developer would have to create a mac-specific GtkMenu object that followed the OS X guidelines and then throw that up. I think putting the burden on the developer in this thing isn't too bad. The Gtk main routine could even be patched to display the initial application menu (with its name). The developer would then put assemble the rest of the menu and throw it up with this API. I haven't done any development work on GTK itself since the 1.2 says, so I can't really say how the best way to actually implement any of this is. What do any GTK developers think of a small API to bridge this gap? > > I'm assuming that the goal is an application that looks & feels as > native as possible and not to replicate the X11 / gnome look & feel. > Both are reasonable goals, but I suspect that more OS X users want > native look & feel. A good start is a normal OS X menu bar. Then work on the look and feel of the actual application windows. A long time down the road too, modal dialog boxes could be implemented OS X-style, sliding out the title bar of the parent window. If somehow GTK became a first-class OS X developer toolkit, I think that would be wonderful. I'm not clear if GTK for OS X is using carbon or cocoa for drawing. Carbon is easiest to use from C, but Cocoa is better in the long run (handles OS X-isms like Command-clicking unfocused windows and scrolling better). > > Is it possible to build gtk for native OS X via jhbuild? > > John > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
I'm sorry for what may be a stupid question. Why do we need a bridge API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) if we're already putting the onus on developers to: 1) Modify their menus to conform to MacOS style guidelines, including putting entries into special menus (e.g. the "Apple" menu), which don't have a GTK+ equivalent 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar 3) Call #2 at appropriate times when different windows get focus (e.g. the Gimp) Wouldn't it be preferable for the developers to just use the Cocoa menu-creation APIs directly? If we were talking about some shim that automatically takes any focussed window's GtkMenuBar and injects it into the OSX menu bar, that might be different. Or if we had the equivalent of Qt's QMainWindow, that might be ok too. But (afaik) we're not talking about that. Best, Dom On 3/28/06, Michael L Torrie <[EMAIL PROTECTED]> wrote: > On Tue, 2006-03-28 at 11:44 -0500, John Ehresman wrote: > > A separate api is probably needed. OS X applications can and should > > display menu bars when no top-level windows are open. Also the > > preferences, quit, and possibly other items should be on the menu with > > the applications name on it instead of the file menu. > > Since preferences and even quit could be anywhere, the app developer > would have to create a mac-specific GtkMenu object that followed the OS > X guidelines and then throw that up. I think putting the burden on the > developer in this thing isn't too bad. The Gtk main routine could even > be patched to display the initial application menu (with its name). The > developer would then put assemble the rest of the menu and throw it up > with this API. I haven't done any development work on GTK itself since > the 1.2 says, so I can't really say how the best way to actually > implement any of this is. > > What do any GTK developers think of a small API to bridge this gap? > > > > > I'm assuming that the goal is an application that looks & feels as > > native as possible and not to replicate the X11 / gnome look & feel. > > Both are reasonable goals, but I suspect that more OS X users want > > native look & feel. > > A good start is a normal OS X menu bar. Then work on the look and feel > of the actual application windows. > > A long time down the road too, modal dialog boxes could be implemented > OS X-style, sliding out the title bar of the parent window. > > If somehow GTK became a first-class OS X developer toolkit, I think that > would be wonderful. > > I'm not clear if GTK for OS X is using carbon or cocoa for drawing. > Carbon is easiest to use from C, but Cocoa is better in the long run > (handles OS X-isms like Command-clicking unfocused windows and scrolling > better). > > > > > Is it possible to build gtk for native OS X via jhbuild? > > > > John > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, 2006-03-28 at 12:19 -0500, Dominic Lachowicz wrote: > I'm sorry for what may be a stupid question. Why do we need a bridge > API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) > if we're already putting the onus on developers to: You know, I don't know. I do know there's probably not a 1:1 mapping between Cocoa and GTK+ menus. > > 1) Modify their menus to conform to MacOS style guidelines, including > putting entries into special menus (e.g. the "Apple" menu), which > don't have a GTK+ equivalent > 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar > 3) Call #2 at appropriate times when different windows get focus (e.g. the > Gimp) Well in the case of 3, Mac users do not expect a menu to change just because they switch windows within an application. The menu should always remain constant. How well GTK apps can be adapted to this paradigm I don't know. > > Wouldn't it be preferable for the developers to just use the Cocoa > menu-creation APIs directly? That is probably a good idea. I don't know enough about Cocoa and Gtk and how they would interact to comment more. You're right, though. This is probably a better idea than any shims. > If we were talking about some shim that > automatically takes any focussed window's GtkMenuBar and injects it > into the OSX menu bar, that might be different. I believe that simply taking the focused window's GtkMenuBar is impractical because there's nothing that says that an window must only have one GtkMenuBar. It could have several. Which one do you use? Further, what do you do when there is no window? What about apps like Gimp where the "main window" isn't really the focus and shouldn't be the menu you want up. Typically OS X apps have one menu only, no matter which window is displaying. > Or if we had the > equivalent of Qt's QMainWindow, that might be ok too. But (afaik) > we're not talking about that. > > Best, > Dom > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Dominic Lachowicz wrote: I'm sorry for what may be a stupid question. Why do we need a bridge API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) if we're already putting the onus on developers to: Because hopefully gtk will make it possible to build a OS X application without any knowledge of the native cocoa api, just as it makes it possible to create apps without knowing the win32 or xlib api's. Over time, methods of creating menus will probably be developed that hide some of the platform differences -- e.g. create a default menu, put in menu bar on OS X or add a copy to the top of each window on X11 or win32. It's more complicated than that, but such a facility should be possible. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Il giorno 28/mar/06, alle ore 18:26, Gustavo J. A. M. Carneiro ha scritto: On Ter, 2006-03-28 at 11:22 +0200, Adriano wrote: [...] I am eager to have a native Gtk+ port on Mac Os X because I hate the poor level of integration of OpenOffice and other Gtk based tools on Mac. Just nitpicking here, but OpenOffice is not Gtk based. It's going to be. I read there are some plans for future versions ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, 2006-03-28 at 10:31 -0700, Michael L Torrie wrote: > I believe that simply taking the focused window's GtkMenuBar is > impractical because there's nothing that says that an window must only > have one GtkMenuBar. It could have several. Which one do you use? A window with multiple GtkMenuBar instances is going to be pretty rare, but taking the first GtkMenuBar child would work in 99.9% of cases I'd expect. Personally I can't think of any applications that have more than one GtkMenuBars in a window. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, 2006-03-28 at 19:33 +0100, Ross Burton wrote: > On Tue, 2006-03-28 at 10:31 -0700, Michael L Torrie wrote: > > I believe that simply taking the focused window's GtkMenuBar is > > impractical because there's nothing that says that an window must only > > have one GtkMenuBar. It could have several. Which one do you use? > > A window with multiple GtkMenuBar instances is going to be pretty rare, > but taking the first GtkMenuBar child would work in 99.9% of cases I'd > expect. Personally I can't think of any applications that have more > than one GtkMenuBars in a window. Sure, but but what about apps like the Gimp. These apps don't fit currently into the OS X paradigm 1:1. OS X apps do not switch menus willy nilly between different windows in the same application. Thus doing some automatic window-menubar mappings would really be bad in the case of the Gimp. > > Ross ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Michael L Torrie wrote: Sure, but but what about apps like the Gimp. These apps don't fit currently into the OS X paradigm 1:1. OS X apps do not switch menus willy nilly between different windows in the same application. Thus doing some automatic window-menubar mappings would really be bad in the case of the Gimp. At best the menu bar would flicker. But this is actually something in the gimp that should be addressed, differently. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, Mar 28, 2006 at 09:34:32AM -0700, Michael L Torrie wrote: > Yup this indeed a stickler. Given the current hodge-podge of menu > creating routines, plus the fact that menus are abstract in GTK (pop-up > menus, menubars, etc) doing this in an automated way seems to be very > difficult. I would be in favor of adding an API that could take a > GtkMenu tree object and stick it up on the OS X menu bar. This way GTK > apps could be modified as needed by the developer to better support OS > X, rather than try to make it automatic. A program like the Gimp, for > example, would pose a real problem to automatically trying to manipulate > the OS X menubar. Which menu do you display? The one on the main > window, the one on the image window? The developer usually has a good > idea of how to deal with that, so providing a simple API for that might > be the best way to go. Of course doing it in such a way that the final > code need not be changed between platforms would still be a challenge. > first of all (*sigh*) gimp is not photoshop. that being said, i would like to point out that when photoshop is working on a macintosh, there are a lot of little windows open all over the place. maybe for any gtk+ application to "feel good" for macintosh users, it is simply a matter of removing menus from places. the idea that macintosh users do not work with dialog windows and such is, in my opinion, over-rated and also inaccurate. /me relurking now, carol ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Hi, before people get the impression that Carol would be speaking for the GIMP developers, I think I better say something as well... GIMP has been brought up as an example of an application that has multiple menubars (albeit not in a single window but in the toolbox and the image windows). As someone already pointed out, this is something that should be addressed in GIMP. We are not at all happy with this situation and plan to merge the toolbox menu into the image window's menu. This is going to happen sooner or later. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, 2006-03-28 at 21:40 +0200, Sven Neumann wrote: > Hi, > > before people get the impression that Carol would be speaking for the > GIMP developers, I think I better say something as well... > > GIMP has been brought up as an example of an application that has > multiple menubars (albeit not in a single window but in the toolbox > and the image windows). As someone already pointed out, this is > something that should be addressed in GIMP. We are not at all happy > with this situation and plan to merge the toolbox menu into the image > window's menu. This is going to happen sooner or later. Great. I'm not criticizing gimp (I must be one of the rare ones that really likes its interface). Just using it as an example of why automatic mapping menu kludges might now always be the best under OS X. Michael > > > Sven > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Tue, Mar 28, 2006 at 11:29:53AM -0800, Carol Spears wrote: > first of all (*sigh*) gimp is not photoshop. that being said, i would > like to point out that when photoshop is working on a macintosh, there > are a lot of little windows open all over the place. > > maybe for any gtk+ application to "feel good" for macintosh users, it is > simply a matter of removing menus from places. > > the idea that macintosh users do not work with dialog windows and such > is, in my opinion, over-rated and also inaccurate. > i do not speak for the gimp developers, nor do the gimp developer speak for me. i am speaking as a gimp user who has seen photoshop being used on macintosh. my memory of this was enhanced by another gimp user who saw the same thing. it might be interesting to look at screenshots of photoshop on macintosh, which, if i am not mistaken, photoshop is native to. i admit, i saw this on television. i do not have access to seeing photoshop on macintosh in real life. so, perhaps my comments are more to the gtk developers who might be given a task that is impossible and based on a rumor that is simply not true. my point is that this goal has not been done even on macintosh before. and it hasn't been accomplished by photoshop (yet) although, there are people who would like others to think so. gimp is not photoshop. they do provide access to accomplishing the same tasks. it should be simple, i guess and maybe someone with access to photoshop (or another multi-window/dialog application) just simply needs to work with it a little to see how the focus work and how the menu/task thing at the top of the macintosh desktop handles the focus of the exisitng multi-windowed applications that run happily on macintosh and with its users. my observation is more like "even photoshop does not do this" and was aimed at the developers (or developer want-to-be's) who might not understand this. it is easy to trap good people with a task which has not actually been accomplished, even by the big guys if i spoke for the gimp developers, i would start by saying i am sorry to me. i don't speak for them. i appreciate the chance to clear this up, whether i wanted this chance or not. carol ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
In my opinion, all this talk about menubars is a bit premature. First the port should be technically complete and released with an official GTK+ release, then interested people can start worrying about making it appear perfectly integrated on OS X. First things first Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Michael L Torrie wrote: Yup this indeed a stickler. Given the current hodge-podge of menu creating routines, plus the fact that menus are abstract in GTK (pop-up menus, menubars, etc) doing this in an automated way seems to be very difficult. I would be in favor of adding an API that could take a GtkMenu tree object and stick it up on the OS X menu bar. A separate api is probably needed. OS X applications can and should display menu bars when no top-level windows are open. Also the preferences, quit, and possibly other items should be on the menu with the applications name on it instead of the file menu. I'm assuming that the goal is an application that looks & feels as native as possible and not to replicate the X11 / gnome look & feel. Both are reasonable goals, but I suspect that more OS X users want native look & feel. Is it possible to build gtk for native OS X via jhbuild? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Mar 28, 2006, at 9:19 AM, Dominic Lachowicz wrote:I'm sorry for what may be a stupid question. Why do we need a bridge API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) if we're already putting the onus on developers to: 1) Modify their menus to conform to MacOS style guidelines, including putting entries into special menus (e.g. the "Apple" menu), which don't have a GTK+ equivalent 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar 3) Call #2 at appropriate times when different windows get focus (e.g. the Gimp) Wouldn't it be preferable for the developers to just use the Cocoa menu-creation APIs directly? If we were talking about some shim that automatically takes any focussed window's GtkMenuBar and injects it into the OSX menu bar, that might be different. Or if we had the equivalent of Qt's QMainWindow, that might be ok too. But (afaik) we're not talking about that. One way to look at it might be similar to how Java on OS X has approached this.By default Java Swing apps being run on OS X have their menus in the windows. However, if they are run with a given property, or have that set in their .jar file, then the menus get repositioned to the top of the screen. There are a few other properties that can change other things. These can also be set from within the program at runtime if desired.This basically gives developers the option of marking their apps as "mac friendly", and also for end users to decide for themselves if needed, even down to a per-run basis.I'd say that being able to have the developers sit happy on their Linux boxes doing work, and end users being able to pull and run the apps without mac-specific tuning would be an ideal goal. The less mac-specific work that's needed, the better. Hopefully that can cover the 99% of most common cases.___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Mar 28, 2006, at 10:23 PM, Jon A. Cruz wrote: I'd say that being able to have the developers sit happy on their Linux boxes doing work, and end users being able to pull and run the apps without mac-specific tuning would be an ideal goal. The less mac-specific work that's needed, the better. Hopefully that can cover the 99% of most common cases. Oh, I thought I'd point out that even though I do most of my development on a G5, I personally try to stick to portable API's and shy away from platform specifics like Cocoa and such. There are also other reasons such as trying to minimize bit-rot, etc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dominic Lachowicz wrote: > I'm sorry for what may be a stupid question. Why do we need a bridge > API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) > if we're already putting the onus on developers to: > > 1) Modify their menus to conform to MacOS style guidelines, including > putting entries into special menus (e.g. the "Apple" menu), which > don't have a GTK+ equivalent I really don't think many (if any) developers will actually consider OS X when creating their menus. It's just not practical to assume they will, and my unsubstantiated assumption is that the vast majority of GTK developers will be targetting X11. (FYI, the Apple menu is not modifiable on OS X by users or app developers. The "application name menu", however, is.) > 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar But who's going to actually do this? Most developers will only use an API if it seems to have an effect on their testing. If they're not testing on OS X, it just doesn't seem likely. > 3) Call #2 at appropriate times when different windows get focus (e.g. the > Gimp) This sounds somewhat kludgy, but I like it the best. The GTK app developer doesn't have to do anything, and the toolkit tries to do what's right for the environment. > Wouldn't it be preferable for the developers to just use the Cocoa > menu-creation APIs directly? Not really. Who's going to actually do it? > If we were talking about some shim that > automatically takes any focussed window's GtkMenuBar and injects it > into the OSX menu bar, that might be different. This is kinda sorta what I'm talking about. My guess is that no one will actually accept it because it's error-prone and a bit of a hack. It doesn't solve all our problems: we won't have a 'Preferences' or 'Quit' menu item in the application name menu, as is normal for OS X apps, and there's of course no guarantee the menu layout will conform to Apple's standards (which I'm not all that worried about). But I think it's a good start, since there's no "real" way to make a GTK app more OS X-like without introducing some backend-specific APIs that no one is going to use. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKjZg6XyW6VEeAnsRAqOiAJ46MhU+kOHRz1JQjcVF0L61I4MAIQCgldsO Z0y86zrCFYuo6Q+XOmzcq2Q= =8FzB -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
All things said... I think that it is silly to assume that poor developers will not do some tweaks for OSX. After all, they will need to make .app bundle and other stuff, just like we are doing for MS Windows. And even if they don't, in the spirit of open community somebody will do that and create native version of Gimp (like now it is with Gimp.app) or Freeciv or whatever... Automatic creation based on currently focused window is just plain wrong. It is not compatible with Apple HIG and it will not even work all the time. What I think will work is to provide OSX top level menu API wrapper in GTK so we can construct our menus for OSX (remember, it will be different then any in-window menu). And if some app does not do that, GTK can create default menu with application name and Quit menu item with Cmd-Q accelerator in it. Just my 0.02$ -- Goran Rakic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Goran Rakić wrote: All things said... I think that it is silly to assume that poor developers will not do some tweaks for OSX. After all, they will need to make .app bundle and other stuff, just like we are doing for MS Windows. And even if they don't, in the spirit of open community somebody will do that and create native version of Gimp (like now it is with Gimp.app) or Freeciv or whatever... Automatic creation based on currently focused window is just plain wrong. It is not compatible with Apple HIG and it will not even work all the time. What I think will work is to provide OSX top level menu API wrapper in GTK so we can construct our menus for OSX (remember, it will be different then any in-window menu). And if some app does not do that, GTK can create default menu with application name and Quit menu item with Cmd-Q accelerator in it. I agree that "automatic creation based on currently focused window is just plain wrong", its true that it would be great if this kind of thing could be done transperently, but only the app writer really knows what should be in the main app menu. I have no idea about how the main menu api works on the mac, but it looks like it can easily translate to a gtk menu bar, maybe I'm missing something but I dont see why it couldn't just be a menubar in the application that has been marked by the programmer as the "main menu". My thoughts on this really are; why should we consider "main menu" capabilities as something unique to the Mac ? I dont see why any window manager shouldn't be able to implement the "main menu bar" shouldnt this kind of thing fit into the "window manager hints" area ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
On Mar 29, 2006, at 1:01 AM, Goran Rakić wrote: All things said... I think that it is silly to assume that poor developers will not do some tweaks for OSX. After all, they will need to make .app bundle and other stuff, just like we are doing for MS Windows. And even if they don't, in Well...I have to disagree with you in general. There are many developers out there who might do some "tweaks" to their app of placing things a certain way, or of adding a marked property to their package... however there are not as many that will do much more than that. There's an entirely different level of effort to do code changes and platform-specific extensions (like Inkscape's support of native Win32 file and print dialogs) than to merely build and package an app for a specific target.Java programs are a good example of this. Even though many would make a Mac launcher of their program, they wouldn't do more than that. And this has been around for years (since the OS 9 days at the least).Of course, some projects will have the people to do this, but then others won't.___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list