I'm just curious whether there is a gui framework that alloys you to use a mac look n feel on other platforms. presumably frameworks that use native APIs wouldn't be helpful (eg wxwidgets).
qt uses native API partially for mac look n feel, so that isn't useful.
what about swing?
In general, don't do this. Different platforms have different conventions, and your software should follow its platform's conventions to minimize the cognitive load of the user.
Unless, I guess, you're the only person who you ever expect to use it.
Legally, you can't create the Mac look and feel on another platform. Apple owns the copyrights to it.
However, the Quaqua Java Look-and-feel implements Java widgets that have that look-and-feel. If you have a good reason to use it in a non-commercial way, it may be a solution.
Every operating system and desktop manager has a different way of implementing GUI elements. Trying to port an application that will look exactly the same as OSX onto these platforms will be difficult if you're looking to use the native controls. Secondly, like Gred stated, each one will have their own way of doing things and could cause user issues by having unusal icons, symbols and controls displayed or missing.
Though if you would like to attempt this, one of the multi-platform web browsers such as FireFox might be able to give you some idea of how to carry over the same general look and feel over the platforms.
Good luck, and hope this helps some.
To answer the last question, Swing does not ship with the Mac look and feel on platforms that aren't Mac-based. This also applied to the other platform-specific look and feel elements.
While not the greatest solution, for Java, the Nimbus L&F is a good alternative... but since it's now included in Java (as of 6u10), it's not available separately any more.
You can implement your own style in Qt [and probably GTK*] to attempt to look the same (see QStyle). However it probably isn't worth the time and effort and will piss off some users. There are some windows themes that attempt to mimic the look. I know the new version of parallels ships with something like that, but it looks rather funny as the margins, spacing, font, etc is completely wrong.
Related
I started my career on Linux/Unix, and moved over to Windows and Visual Studio. XCode feels pretty alien to me. My feeling is that I'm not in control with XCode. It could be the case that I simply haven't understood how to use the IDE, I am new at developing for Apple OSs. One thing that kind of irks me, is that nobody seem to have found a clean way to compile for multiple platforms (iOS and Mac OS X), using the same sources. I've found two ways to "hack it", but the hacks sound fragile.
I've been pondering the idea of using simple make files instead of XCode (except for the occasional use of Interface Builder).
Is this a sane route to go? Has anyone done this? Are there any major drawbacks I need to be aware of before I take the leap, or should I just bite the bullet and wait for the enlightenment?
Use Xcode, use as many high-level tools as possible. The "loss of control" is replaced by more focus on the application, which IMHO is a great tradeoff.
It is kind of like the loss of control when I went from assembly code to "C", but it was worth it. We keep moving to higher level of abstraction and that allows us to accomplish more, focus on the big picture instead of the minor details.
You've just got to learn new ways of doing things. For example, in the situation you describe (building an OS X and iOS app with shared code), I'd put any shared code into a library/framework that is used by both projects, and create a workspace that contains all three projects.
The loss of control you speak of is offset by the fact that this can all be set up without knowing anything about compiler command-line options in around 10 minutes.
It's a different way of thinking, and it can be frustrating if you know how you would do it on a different platform, but there are advantages to both options. You may never have to think about the build process again!
We have a large console application in Haskell that I have been charged with making cross platform and adding a gui.
The requirements are:
Native-as-possible look and feel.
Clients for Windows and Mac OS X, Linux if possible.
No separate runtime to install.
No required network communication. The haskell code deals with very sensitive information that cannot be transmitted over the wire. This is really the only reason this isn't a web application.
Now, the real reason for this question is to explain one solution I'm researching at the moment and to solicit for reasons that I'm not thinking of that make this a bad idea.
My solution is a native gui. Winforms on Windows, Cocoa on Mac OS X, and GTK/Glade on Linux, that simply handles the presentation. Then I would write a layer on top of the Haskell code that turns it into a responder for messages to and from the UI using ZeroMQ to handle the messages and maybe protobufs for serializing the data back and forth. So the native application would start which would itself start the daemon where all of the magic happens, and send messages back and forth.
Aside from making sure that the daemon only accepts connections from the application that started it, and the challenge of providing the right data back and forth for advanced gui elements (I'm thinking table views, cells, etc.), I don't see many downsides to this.
What am I not thinking about that makes this a bad idea?
I should probably mention that at first glance I was going to go with GTK on all platforms. The problem is that, while it's close, and GTK and Glade support for Haskell is nice to work with, the result doesn't look 'right'. It's close, but just not native enough in subtle ways which make that solution unacceptable to the people who happen to be writing the check for this work.
Also, the issue of multiple platforms and thus multiple languages for the gui isn't a problem so I'm not necessarily looking for other ways to solve that problem unless it simplifies something about the interop with the haskell code.
Then I would write a layer on top of the Haskell code that turns it into
a responder for messages to and from the UI using ZeroMQ to handle the
messages and maybe protobufs for serializing the data back and forth.
I think this is reasonable (a client/server model, where the client just
happens to be a native look-n-feel desktop app). (I have no strong view
about protobufs versus e.g. JSON, thrift).
The Haskell zeromq
bindings are getting
some use now, too.
What am I not thinking about that makes this a bad idea?
How well tested is zeromq on Windows and Mac? It is probably fine, but
something I'd check.
The problem is that, while it's close, and GTK and Glade support for
Haskell is nice to work with, the result doesn't look 'right'.
Does the integration package help
there?
Here's an interesting possibility: wai-handler-webkit. It essentially packages up QtWebkit with the Warp web server to make your web apps deployable. It hasn't seen intensive use, has never been tested on Mac, and is tricky to compile on Windows, but it's a fairly straight-forward approach that lets you use the fairly rich web ecosystem developing in Haskell.
I'm likely going to be doing more development on it in the near future, so if you have interest in using it, let me know what extra features would be useful, as well as if you could offer any help on the Mac front in particular. I'm also not convinced that we need to stick with QtWebkit on all platforms: it might make more sense to use a different Webkit backend depending on OS, or maybe even using Gecko or (shudder) Trident instead.
I've had some problems getting zeromq to play nice with haskell on OSX (problems with looking for a dylib as opposed to an "o" I think). Protocol buffers and haskell seems to work fine though.
So your reason not to use a web application is because of sensitive nature of haskell program's output. And THAT's why you are distributing that same sensitive application that spews out unencrypted data on ALL client machines ? That does not make any sense.
If your application is sensitive you DEFINITELLY should put it on server and utilize strongest possible TLS.
There are many applications for Windows these days that don't use native windows controls, don't have standard window frames and generally look different. What are some recommended techniques for creating such interfaces?
There are good reasons not to. Like that you will most likely not do a better job than Windows does. (Maybe it will look better (in your opinion), but will it behave?). Or that it's not what most users expect. Or that it will look like s**** on Windows 2011.
That said, it's not hard. You simply handle the WM_NC* events like WM_NCPAINT or WM_NCHITTEST. NC stands for Non Client (window area). And of course, there is a trick on Vista/Win7 (you have to announce it to the DWM).
From an implementation aspect, you could employ WPF (Windows Presentation Foundation) assuming you code for .NET :) It has pretty bunch of skinnable controls, that may look like native and may not.
From a design aspect, if your interface isn't going to follow documented standards (like the Windows UI guidelines), it has to be intuitive. I think the new generation of Windows applications will go through a growing phase in a manner similar to the early days of the Web. After a time, some standards or common themes will evolve.
Can you give us some sample applications? Some apps that don't use native windows controls use cross-platform GUI libraries, like Qt for C++ or Tkinker. These maintain the same look across different platforms.
I wouldn't really recommend making your user interface different deliberately. You don't stand to gain much. Your controls are almost always going to be buggier than native controls, and you are requiring the user to learn something new. Now, if you're controls add a large enough value to be worth the users' time it can be okay. But making them get used to different looking buttons is rarely worth it.
I`m not sure if this answer your question.
You can use third party skinning controls like from Infragistics, or SkinSoft for example.
But like Bubba said I`d recommend going for WPF.
Model-View-Controller! It's as valuable here as in web apps or anywhere else. Be sure to keep the part of your program that generates the custom UI separate from the part of your program that flashes the BIOS.
I know this question is 10 years old but none of the answers mention using an option in visual studio, dont know if it existed at the time.
Theres an option to remove the border of the window in visual studio (called borderStyle). Thats the easiest way to do it, using C#. After removing the border, all you have to do is create a new interface. If you're looking to do it in C++, i think you need to use DWM. I will let an example i found here.
https://github.com/melak47/BorderlessWindow
Another example (maybe without DWM? didnt test):
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b98c4c06-9581-44d3-8e5a-4adb2316e653/win32-about-styles-how-can-i-do-a-borderless-window?forum=vclanguage
There is a lot of people disencouraging to do it in this thread but there's no reason to not do it, if you know what you're doing your application can look great.
I'm now with a idea to start the development of a bare bones Qt/GTK+-like framework, but I want to know some things before I start the creation of this project:
What is the structure of GTK+ and Qt?
Do I need to develop a window manager to build my own framework?
Some resources to start?
Developing a GUI/Application framework is a significant undertaking. You might want to be very clear about why you need to write yet an other framework.
Both projects you mention are open source. Why not start there?
GTK: git clone git://git.gnome.org/gtk+
Qt: git clone git://gitorious.org/qt/qt.git
Ed You ask what the structure of GTK and Qt are, whether you need to write your own widow manager (answer: no) and how to get started. Answers to at least the first two are in the source code. Don't forget, great practitioners in any field learn by watching others. Reading code is no different.
Writing a GUI/app framework would be a great learning experience, but even a fairly small app framework would be a very big job, and not something you really should tackle until you're fairly expert in writing applications using several other frameworks and widget toolkits.
I did something like this once, back in the early years of this decade. That was after I'd been programming for the Mac for over 15 years, Windows over 10, and had programmed both directly to their native graphics, event, and widget APIs, as well as various object-oriented toolkits for them including PowerPlant, MFC, and MacApp. When I started working on a PalmOS application, I spent a couple of weeks writing a very small app framework modeled on PowerPlant. But I could not have succeeded at all without those decades of broad and deep experience with so many GUI systems.
Doing this for Linux/X11 is even more work. That's because, unlike Mac OS and Windows, neither X11 nor Linux supply built-in user interface widgets, or much in the way of graphics primitives or text layout capabilities. GTK+ is part of the GNOME ecosystem; it provides the widgets, gets its message queue and internal communications from GObject, relies on GDK to abstract and simplify its graphics and event communications with X11, and uses Pango and Cairo for text rendering and layout. I work all through that system, and it probably represents many dozens of person-years of hard work by a lot of really smart people. And I'm sure Qt is very similar.
So if you really want to do this, I would recommend you:
Write programs with a lot of different app and widget toolkits, on multiple operating systems. That will help you learn not just how such systems work, but why they are designed as they are. And it will give you some feeling for what works well, and what works poorly.
Contribute bug fixes or new features to one or more of the various open-source frameworks. GTK+ has a list of tasks for beginners to work on. Another great open-source framework is wxWidgets.
Become an expert-level C/C++ programmer.
When you've done that for a few years, you will have the expertise suitable for tackling your own framework.
That sounds like a major undertaking, at least as a starting project.
Not sure what you mean by "the structure" of e.g. GTK+. You can see the object hierarchy for GTK+, that tells you at least how the implemented objects (GTK+ is an object-oriented API) relate to each other. You can guess how the code can be structured, from that information.
And no, you don't need to write your own window manager; the toolkits mainly concern themselves with what happens inside windows, not with the window management itself. Of course you could decide that your "platform" should have a wider scope, and include a WM.
I think some of the answers here might exaggerate a bit. Obviously making something of the same quality, width and depth as Qt and Gtk is a huge untertaking. But you can make simpler stuff and still learn a lot about how it works. I suggest doing like I did in university. Use OpenGL with Glut. Then you got basic drawing functionality and event system in place already. You then need to create classes for buttons, text fields etc.
If you want to make it really simple then each component just needs to know where it is drawn and have some sort of bounding box where you check whether mouse click are inside or not. You also needs to create some system which makes it possible for buttons, check boxes etc to tell the rest of your code that they were clicked.
This isn't really the rocket science people here make it out to be. Games have made their own very simple GUI toolkits for years. You can try that approach as well. I have modeled a simple GUI tookit on top of a game engine before. Your buttons and textfield could be simply be sprites.
But yeah, if you want to make something that will compete with Gtk+ and Qt, forget about it. That is a team effort over many years.
Is it worth to try to keep your GUI within the system looks ?
Every major program have their own anyways...
(visual studio, iexplorer, firefox, symantec utilities, adobe ...)
Or just the frame and dialogs should be left in the system look 'n feel range ?
update:
One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.
I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.
So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...
I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).
So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.
If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.
Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.
Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.
I tend to agree with others here- especially Soraz and Smaci.
One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).
The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).
You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).
I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!
The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.
Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.
I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.
Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.
Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.
I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)
The question is 'Is it worth breaking the OS look and feel?'
In other words,
Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
What do you gain from doing so? (Improvinging usability?)
What do you lose from doing so? (Intuitiveness & familiarity?)
Don't simply do it 'To be different'
It depends on how wide you would define system look'n feel... But in general, you should keep it.
Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)
Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.
Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.
Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.
If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".
See Are there any standards to follow in determining where to place menu items? for more information.
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.
I strongly recommend making your application look native.
A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.
No, the new application should look-and-feel like all the other application that the user is used to on the new platform.
Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.
You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.
Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.