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
GTK+ team irc meeting
HALF AN HOUR EARLIER ! The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 20:30 UTC (15:30 EST), Tuesday March 28 ___ 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: The printing work has been merged
Am Montag, den 27.03.2006, 17:26 +0200 schrieb Alexander Larsson: > > I have a question about generating postscript. Using > > copy/paste method I implemented postscript print backend, > > and it's working fine. While generated postscript is just > > a bunch of page images due to cairo problems, the GtkPrint* > > stuff works fine. So, shouldn't PDF backend be really a > > "File" backend which can write PDF or PS? Or maybe just > > separate PS backend, in addition to PDF? > > Do we want to expose a write-to-ps to everyone? PDFs are a well known > way to send pre-rendered page layouts as files, but postscript is much > less widely known. Two points to consider: * PostScript is the standard output format in the natural sciences and mathematics community. (Probably due to the prominence of LaTeX and dvips.) Also, since it's understood by many (semi-)professional printers it is often used for production of papers and preprints or as an intermediate format. On the other hand the only applications that would fit into this category are probably word processors, so general PostScript support is not necessarily needed. * PDF and PostScript have a slightly different application, in my opinion. PDF is used for "web publishing", i.e. stuff that's to be read online, but can also be printed out. It has lots of features that don't make sense on paper (links or automatic table of contents, for example). PS on the other hand is the lingua franca for communication with printers (the hardware kind). If you've got something as PS on Linux you can print it, transform it, do all kinds of silly stuff that falls into the "print preparation" category. It's a format very well suited for a (printer independent) "Print to file" option. - Sebastian ___ 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: The printing work has been merged
Sebastian Rittau wrote: >Am Montag, den 27.03.2006, 17:26 +0200 schrieb Alexander Larsson: > >> > I have a question about generating postscript. Using >> > copy/paste method I implemented postscript print backend, >> > and it's working fine. While generated postscript is just >> > a bunch of page images due to cairo problems, the GtkPrint* >> > stuff works fine. So, shouldn't PDF backend be really a >> > "File" backend which can write PDF or PS? Or maybe just >> > separate PS backend, in addition to PDF? >> >> Do we want to expose a write-to-ps to everyone? PDFs are a well known >> way to send pre-rendered page layouts as files, but postscript is much >> less widely known. > >Two points to consider: > > * PostScript is the standard output format in the natural sciences >and mathematics community. (Probably due to the prominence of >LaTeX and dvips.) Also, since it's understood by many >(semi-)professional printers it is often used for production of >papers and preprints or as an intermediate format. On the other >hand the only applications that would fit into this category are >probably word processors, so general PostScript support is not >necessarily needed. > * PDF and PostScript have a slightly different application, in my >opinion. PDF is used for "web publishing", i.e. stuff that's to >be read online, but can also be printed out. It has lots of >features that don't make sense on paper (links or automatic >table of contents, for example). PS on the other hand is the >lingua franca for communication with printers (the hardware >kind). If you've got something as PS on Linux you can print it, >transform it, do all kinds of silly stuff that falls into the >"print preparation" category. It's a format very well suited for >a (printer independent) "Print to file" option. > > - Sebastian Printer manufacturers have been moving from PostScript to PDF over the last few years. At the Linux Printing summit next month one of the agenda points will be the transition from postscript to PDF as the primary format used by the Linux printing infrastructure. I'm sure postscript will remain supported for some time to come, but it's definitly on its way out. Waldo Bastian Linux Client Architect - Channel Platform Solutions Group Intel Corporation - http://www.intel.com/go/linux OSDL DTL Tech Board Chairman ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
On Tue, 2006-03-28 at 21:05 +0200, Sebastian Rittau wrote: > Two points to consider: > > * PostScript is the standard output format in the natural sciences > and mathematics community. (Probably due to the prominence of > LaTeX and dvips.) Also, since it's understood by many > (semi-)professional printers it is often used for production of > papers and preprints or as an intermediate format. On the other > hand the only applications that would fit into this category are > probably word processors, so general PostScript support is not > necessarily needed. > * PDF and PostScript have a slightly different application, in my > opinion. PDF is used for "web publishing", i.e. stuff that's to > be read online, but can also be printed out. It has lots of > features that don't make sense on paper (links or automatic > table of contents, for example). PS on the other hand is the > lingua franca for communication with printers (the hardware > kind). If you've got something as PS on Linux you can print it, > transform it, do all kinds of silly stuff that falls into the > "print preparation" category. It's a format very well suited for > a (printer independent) "Print to file" option. An interesting counter-point is that we designed our own wedding invites, and when we got them printed the printers (a very large chain in England called Prontoprint or something) wanted source documents in PDF. They accepted PostScript if required but preferred PDF, as the documents are less complicated, less prone to being targeting at particular printers, and generally easier to print. The same happened when I got some artwork printed on A2 card at another large chain (Kallkwik this time): they claimed to accept Postscript but when pushed (by mailing them CUPS postscript) admitted they import the Postscript into Adobe Illustrator, so really want AI files. Or PDF of course. I ended up sending PDF as neither Inkscape or CUPS would write PostScript close enough to the PostScript that AI read. 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: The printing work has been merged
Ross Burton wrote: An interesting counter-point is that we designed our own wedding invites, and when we got them printed the printers (a very large chain in England called Prontoprint or something) wanted source documents in PDF. They accepted PostScript if required but preferred PDF, as the documents are less complicated, less prone to being targeting at particular printers, and generally easier to print. The same happened when I got some artwork printed on A2 card at another large chain (Kallkwik this time): they claimed to accept Postscript but when pushed (by mailing them CUPS postscript) admitted they import the Postscript into Adobe Illustrator, so really want AI files. Or PDF of course. I ended up sending PDF as neither Inkscape or CUPS would write PostScript close enough to the PostScript that AI read. This only proves that PDF is important. But nobody said that PS should be preferred or something! The point is that postscript is important enough to be present in Print dialog. Of course lot of people want PDF; postscript on windows (where acrobat products are used) is something really rare. It's just not a reason to make *only* PDF available. Regards, Yevgen ___ 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
