 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / May 2006Enhancing the look of Motif apps in MacOSX
Hi, I'm porting my UNIX Motif applications to wxWidgets, but I've some users who are asking me for an early access to the OSX version of my apps. I didn't finish the port to wxWidgets yet, but I can compile them with OpenMotif. However, the look is too old-fashioned. I saw the OSX version of Gimp. It's not a native port, as it requires X11 to run, but however the look is reasonably acceptable, and looks almost if it had been ported to Carbon. I guess this will be because GTK will have some sort of Aqua-like theme. Is there something I can do for enhancing the look of my apps under OpenMotif, or am I limited to the old-fashioned look until I finish the port to wxWidgets? Thanks. nopa In comp.sys.mac.programmer.help nopa <nopaperfound@yahoo.com> wrote: > Hi, > [quoted text clipped - 11 lines] > OpenMotif, or am I limited to the old-fashioned look until I finish the > port to wxWidgets? I think that Mac users are much more demanding than you believe. (Or perhaps they're less demanding than I believe....) Nothing X11 is even vaguely acceptable as a "real" Mac app. I use Gimp in X11 occasionally, but I'm also familiar with other UNIX systems, and I still don't like to use it. It looks nothing like a native app, and behaves nothing like a native app. Unless your program is highly specialized and you can individually train your users, X11 should not even be considered. If you're releasing to the general public, most of your potential users won't even have X11 *installed*, much less understand how to use it. It sounds like your user base for now is people who are already familiar with your software on other systems and so are more likely to be savvy, but presumably you may want to reach new users on the Mac as well once you release the port. You should note that wxWidgets, while it looks significantly better, is *still* noticeably different and disconcerting compared to real native Mac applications. Consider doing a Cocoa or Carbon port, at least at some point later on.  SignatureMichael Ash Rogue Amoeba Software > In comp.sys.mac.programmer.help nopa <nopaperfound@yahoo.com> wrote: > [...] > I think that Mac users are much more demanding than you believe. (Or > perhaps they're less demanding than I believe....) No, I don't plan to use X11 as a desired target, but only as a temporal workaround. Regarding Gimp, yes it's not native, but it looks much better than OpenMotif, and that's what I'm looking for (ie: some visual enhancement for OpenMotif, if such thing exists). [...] > You should note that wxWidgets, while it looks significantly better, is > *still* noticeably different and disconcerting compared to real native Mac > applications. What makes a "real native Mac app" isn't just Aqua and Cocoa. It's more than that. A single read to the Apple HI Guidelines is enough for realizing that you can create a non-native Mac app no matter if you directly use native APIs like Carbon or Cocoa. wxWidgets has two OSX ports: A Carbon port (in mature status), and a Cocoa port (in experimental status). It uses the native Apple APIs for almost everything. The developers of these two ports are making great stuff... even the standard menu options go automatically to the places Apple mandates. It's true that they used some non-native custom controls in the first versions, but they've been moving towards an all native implementation. The last feature is native toolbars, IIRC. The fact is that if you follow the Apple HI Guidelines, you can create a real native Mac app with wxWidgets, and nobody will notice that you used wx. And if you don't follow that book, your app won't be native even if you use Apple APIs. Of course, if you write an wxWidgets app with a UNIX mind, don't expect it to translate to a real Mac app when you compile on OSX. As a side comment, I decided to stop making my software depend on closed-source commercial APIs after seeing that no computer business is really committed to the technology they develop. They'll drop their APIs for whatever reason dictated by the market, even if their APIs are technically superior to their competitors. They won't fight for defending their technology. I've seen this too many times... Beta video tapes, Silicon Graphics IRIX OS, several Apple APIs, including Altivec support, processor endianness, DirectX substituting OpenGL (I wouldn't be surprised to see Apple dropping OpenGL in favor of DirectX some day). Vendors won't defend their technology, so I can't make my code depend on something nobody will defend. That explanation is perhaps the main reason why I'm directly porting from X11 to wxWidgets, without considering Win32, nor MFC, nor Carbon, nor Cocoa, nor nothing. If some day I see a computer maker fight for their technology instead of their shares values in the short-term, I might change my views. nopa In comp.sys.mac.programmer.help nopa <nopaperfound@yahoo.com> wrote: >> In comp.sys.mac.programmer.help nopa <nopaperfound@yahoo.com> wrote: > [...] [quoted text clipped - 22 lines] > Of course, if you write an wxWidgets app with a UNIX mind, don't expect > it to translate to a real Mac app when you compile on OSX. In theory, you are of course correct. However, in practice I have a difficult time finding any Cocoa app which does not look and feel native. Carbon apps are more hit-and-miss, but are generally good. And I have never seen a wxWidgets app that looked or felt remotely native. There was a thread in the comp.sys.mac.programmer hierarchy a month or three back which discussed this in fairly deep detail. Various wxWidgets programs were proposed with the idea that they feel native, and they really did not. No doubt you can make a fully native-look-and-feel app with an API like wxWidgets, but you will have to do a *lot* of extra work. Using Cocoa or Carbon usually means that you start out native, and have to work to make it un-native. What's possible is the same for either, but what actually *happens* is generally not. > As a side comment, I decided to stop making my software depend on > closed-source commercial APIs after seeing that no computer business is [quoted text clipped - 6 lines] > be surprised to see Apple dropping OpenGL in favor of DirectX some > day). Right, Apple is going to throw out the drawing API upon which *every other drawing API on the system depends*. Apple is not as insane about backwards compatibility as Microsoft is, but they try not to break old apps. They still support QuickDraw! Of course if you are sufficiently paranoid and refuse to have any code that could be rendered useless, then your attitude makes some sense. I have no idea what processor endianness has to do with anything. The only technical value in either is consistency. > Vendors won't defend their technology, so I can't make my code depend > on something nobody will defend. > > That explanation is perhaps the main reason why I'm directly porting > from X11 to wxWidgets, without considering Win32, nor MFC, nor Carbon, > nor Cocoa, nor nothing. Normally you'd have a large kernel of portable code with a thin wrapper using whatever platform-specific API is needed to get a decent program running. If a company implodes or turns stupid, you just lose the thin wrapper, nothing more. > If some day I see a computer maker fight for their technology instead > of their shares values in the short-term, I might change my views. Nothing says wxWidgets couldn't just implode one day as well. Yes, it's open source, but if everybody else stops working on it, can you really maintain it for all of your target platforms single handedly? Anyway, I'm not trying to be argumentative, nor am I even trying to change your choices, but just pointing out that there are advantages to using the official API, and that it may not be as bad as you fear. Of course if you don't want to use them, that's entirely up to you. SignatureMichael Ash Rogue Amoeba Software > In comp.sys.mac.programmer.help nopa <nopaperfound@yahoo.com> wrote: > >> In comp.sys.mac.programmer.help nopa <nopaperfound@yahoo.com> wrote: > > [...] > Right, Apple is going to throw out the drawing API upon which *every other > drawing API on the system depends*. I'm sure they wouldn't doubt to drop OpenGL as the system graphics API, first of all because Apple doesn't own OpenGL. Nowadays, for proper OpenGL operation you depend on PC hardware designers (nvidia and ati). If OpenGL becomes an obsolete API in the PC market (as Microsoft is trying to achieve), then I don't see any reason why Apple wouldn't follow the same path and move towards what nvidia and ati support best. Maybe I'm too old, or too paranoid, but the thing I've learned best in the computer world is that there isn't any company committed to their technology. They just care about shares values. Sell a lot, sell it cheap, and make easy money. That's it. Who cares about OpenGL? Just the applications ISVs, because of their investment in writing code for that API, and because they're the ones who need to be close to the API details and because of this they can appreciate and prefer good designs over trashy ones. But neither OS companies, nor hardware designers, nor computer vendors, nor users care about it. If Apple thought that being dependent on PPC processors could be risky, and so made OSX with initial support for Intel, why wouldn't they feel the same about OpenGL, being a technology they don't own? Just like you, I don't pretend to be argumentative about my choice of "use as few closed source APIs as possible, and when you do it encapsulate the code", but that's my preference, I believe the multiplatform framework way is the best, at least for me. I'm also a person who cares about the details, so if I develop for Mac, I care to follow the HI guidelines as much as possible. The same applies when I develop for UNIX or Windows. nopa > I'm porting my UNIX Motif applications to wxWidgets, but I've some > users who are asking me for an early access to the OSX version of my [quoted text clipped - 9 lines] > OpenMotif, or am I limited to the old-fashioned look until I finish the > port to wxWidgets? At the very least, try the following resource values if you haven't already. They change the look from the ca 1990 original ugly Motif to the ca 1996 "CDE look" (thin frames, menus appearing etched-in instead of raised, different appearance for checkboxes and radio boxes, etc): *enableThinThickness: True *enableEtchedInMenu: True *enableToggleColor: True *enableToggleVisual: True These should be in everyone's .Xdefaults file IMHO. Try "man XmDisplay" for more info. You can also change the colours or specify XPM files as the backgroundPixmap for some or all widgets if you really want to make an effort. SignaturePer Espen Hagen My TLD is CC > You can also change the colours or specify XPM files as the > backgroundPixmap for some or all widgets if you really want to make an > effort. Thank you, I didn't know xpm backgrounds were possible for motif widgets. I might invest some time experimenting with this, and it may indeed improve the look, at least for reducing the "80s look". I'll also set the app resources to your suggested values. Thanks a lot for the help!! nopa > Thank you, I didn't know xpm backgrounds were possible for motif > widgets. They sure are. Just try to run nedit or some other Motif app like this: nedit -xrm "*backgroundPixmap: /path/to/some/file.xpm" However, widgets cannot be transparent so each widget will have its own pixmap tiled from the upper-left corner. Gadgets (which have no window) will have the parent widget's pixmap though. SignaturePer Espen Hagen My TLD is CC > > Thank you, I didn't know xpm backgrounds were possible for motif > > widgets. [quoted text clipped - 6 lines] > pixmap tiled from the upper-left corner. Gadgets (which have no window) > will have the parent widget's pixmap though. Do you mean that it's not possible to set some colors in the pixmap as "none" so that they're transparent? (it would be nice if that feature was supported, because I could give a bit of rounded appearance to the widgets corners). nopa >>However, widgets cannot be transparent so each widget will have its own >>pixmap tiled from the upper-left corner. Gadgets (which have no window) >>will have the parent widget's pixmap though. > Do you mean that it's not possible to set some colors in the pixmap as > "none" so that they're transparent? (it would be nice if that feature > was supported, because I could give a bit of rounded appearance to the > widgets corners). No, that won't work if I understand you correctly. Transparent ("none") pixels in the XPM file will just show the widget's background colour. SignaturePer Espen Hagen My TLD is CC So, back to the original question, does anyone have an answer on how Gimp does it? I could care less about your style debate--I also want my X11 applications look vaguely similar to native MacOS X applications, and I believe the original poster wants to know how to do that and it hasn't been addressed by anyone yet. Thanks! >Hi, > [quoted text clipped - 15 lines] > >nopa |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.