Guest post by This is a call out for help on creating a consistent and native feeling on Mac OS X and Linux. As I have never owned a Mac and haven’t used Linux as my main OS for over 3 years I need the community of OSAlert to help me do this.
The importance of consistency
Consistency in design is important.
It allows users to use existing knowledge and thus makes it easier when being confronted with a new interface. If the whole system uses certain design principles, common layout, and wording of error messages, a good designer should use this to his advantage.
One of the first thing students in Human-Machine Interaction learn is how familiarity makes it easier for a user to get started with a new application. A lot of text books teach the reader how to consider spatial memory, visual perception and embodied cognition during design. Students learn the difference between working memory, long-term memory and short-term memory. Why humans remember things and why they forget. This is important knowledge to consider when designing a successful and easy-to-use interface.
For some reason all this knowledge is thrown away when it comes to real world development. Looking at music players for Windows 7 as an example, it is easy to see that each application sports its own interface principles, its own look and feel, its own way of structuring data and controls, its own world. Each new to the user. Each slightly different.
The Stoffi project
I will try not not make this article into a large ad for my project but a little history is still needed. For those of you not interested it’s OK to skip this section and go right to the last (next) one.
The Stoffi project is an attempt to take what makes all music players great (such as a queue, history list, automatic scanner, silent upgrades, and vast support for file formats) and put these features into an interface that has been tailored to the operating system it runs on. The first being Windows 7.
It uses Jumplists, buttons in the taskbar previews, scans Windows 7 Libraries of type Music automatically, comes with an interface that is highly inspired by “native” applications such as Windows Explorer and the Control Panel. All with the aim of feeling like it was shipped with Windows 7 and more a part of it than a third party application.
Using the power of the community
Now the turn has come to other operating systems. Work has started to port this project to both Linux and Mac OS X. As I am not very familiar with OS X (I have never owned a Mac) and I have been away from KDE for 5 years and Gnome for 3 years, I need your help to create this same feeling of a “native” application.
So please, tell me in the comments what I should focus on, where should the interface draw inspiration from, what principles need to be adhered to, what should I avoid. Are there any features that should be included (like how Windows 7 has Libraries, Jumplists and Taskbar thumbnails)? Anything from installation, upgrades, look, feel, icons, dialogs or message phrasing.
No user, no matter his platform of choice, should ever feel like a second class citizen. Each user should get the impression that the application was designed for his operating system only.
About the author
Christoffer Brodd-Reijer is a student at Uppsala University in Sweden where he studies computer science. In his spare time he works on his pet project Stoffi or reads articles and comments on OSAlert.
Use The Qt4 library — it is the closest you can get to a native look & feel, while still retaining cross-platform code portability.
-Technologov, 23.01.2012.
Definitely not this — using any toolkit (even a very good one such as Qt4) is a surefire way to create a almost-but-not-quite-native-looking UI, which is the opposite of what the author seems to want.
In that case your Linux client should be CLI only :p
Joking aside, I like the aim you’ve set yourself. I’ll be interested to see how your other clients pan out.
[edit]
I meant to post this as a new comment rather than a reply *blush*
Edited 2012-01-23 14:18 UTC
Tbh, that’s the only way I got a consistent look on both my Linux/BSD and OSX setups. Putting a tiler like Xmonad or ScrotWM on top of OSX’s UI, rxvt-unicode for terminal emulator, mutt for email, mpd+ncmpcpp for music, vim for editing….etc. Was a bit of a pain to set up some of em in OSX (even with macports), but the end result was pretty consistent. =P
Sorry for going off on a tangent, but I think this goes some way in emphasizing the measure of the challenge that awaits him with regards to getting a uniformed look on Windows, Mac and Linux operating systems.
Edited 2012-01-23 14:27 UTC
Well I think it would be time well invested since I am really looking forward to doing an interface for each environment. I am well aware of the challenges, that’s the fun part!
Qt is good enough to be portable.
Though IMO Qt is the best cross-platform UI toolkit; it produces a 99.9% native look and feel in Windows, Linux and Mac OS X… the problem is that 0.1% not covered.
A lot of users (Apple fanboys) will say your application “does not feel native” although all the effort made following that direction.
I suggest you creating an abstraction layer to access the backend of your whole application and interface such abstraction layer with a native frontend (built in the UI framework of the platform you are targeting: Cocoa for Mac, Qt with kdelibs or GTK+ for KDE/Gnome/Xfce, etc and Windows Forms, WPF or MFC or Win32 for Windows).
Yeah, I am aiming at creating a GUI for KDE and Gnome each since I want really, really, really tight integration with each DE (and of course then move on to LXDE, XFCE, Fluxbox, etc, etc. if there’s time).
I think you might be able to combine your GNOME, XFCE, and LXDE efforts into a single GTK-based UI. As an LXDE user , I’m not sure what added functionality the other GTK-based DEs might natively offer
Perhaps I might. But you have to consider the difference between Gnome 3 and LXDE for example. But I haven’t used Gnome 3 or XFCE or LXDE very much. So perhaps someone here could tell me if there are any differences worth considering when creating a custom tailored GUI?
Maybe on Linux I will be able to create a Qt interface and a GTK interface and by that cover most popular DEs. E17 and Blackbox/Fluxbox will require their own interfaces though but I’m not even sure which C# bindings I should use in those environments.
Oh gosh. C#… Really?
I’m sorry. You have just told me what your coding style is and your selection of using C# is a horrible thing.
*YES* I know C# is the wave of the future. I’ve heard that from everything Microsoft over and over again.
Good luck when Microsoft decides to stop “ignoring” Mono on non-native Operating Systems. Yes, I realize they have a covenant… but its a decision. How many times has Microsoft become an “Indian giver”.
Its just a matter of time until they overturn their decision to “not sue”… WTF is that anyway.
Dealing with Microsoft Technology on any front is a dance with the Devil on any terms, including on Windows.
Well their promise not to sue is in written form and on “alternative” platforms I will avoid the System.Windows namespace like the plague (since that part is not included in their license). That is good enough for me and I choose to be an opportunist.
C#? Your Mac port is already toast. You’ll either have to wrangle the Mono framework as a built-in dependency or convince your users to install it for system-wide use. Good luck with that.
The situation is a lot less dire on Linux, where GNOME flirted with Mono for a long time before Vala showed up, but you’ll still need to check dependencies.
Your best bet would be to rewrite the core/server code in C, or at least in a language that compiles to C and exports C APIs (only Vala comes to mind). Of course, then you have to worry about the fact that each environment does audio differently…. Come to think of it, this is a very silly project.
Edited 2012-01-24 22:42 UTC
FYI – you can do that with Qt. It supports a Gtk theme so that it looks native under Gtk/GNOME too. No need to do both Gtk and Qt separately. (AFAIK, you can’t do that with Gtk.)
Well to start with the C# bindings for Qt are very badly supported.
Secondly, and more importantly, if we discard the “look”, let’s focus on the “feel”. For example we have different ordering of OK/Cancel buttons. There’s also the configurability of the DEs themselves which sets a different environment for the user.
Are there any other differences between Qt apps and GTK apps when it comes to feel?
C# is pretty much only Windows. Yes, I know Mono/etc. exists; but it will never be on part with .Net on Windows; and anyone serious about programming for multiple operating systems – or even non-Microsoft operating systems – will NOT use C#. Thus why it is badly supported, which BTW it’s not officially supported by the Qt folks any way. So you’re barking up the wrong tree there.
Your mixing apples and oranges by trying that.
You’re way off the target on this one. See below.
So needless to say, that’s a misnomer in this whole discussion.
Another misnomer. You’re comparing what KDE does versus GNOME or Microsoft. Those are each groups that use toolkits for the platform, and have their own platform designs. But in now way do the necessarily overlap in how they do those things, and its not the job of the toolkit to make that jump.
So, while you can get the look and feel – native theming in Qt speak – there will always be things that the toolkit itself can’t account for in making those changes.
For example, the toolkit cannot necessarily tell the difference between an OK and CANCEL button. Even if the toolkit provided distinct controls for those two that could be used (which almost none do, btw) you’d still have to get every application to use those distinct controls instead of just using a simple randomly named button with the text OK or CANCEL.
The same goes for how the dialog itself is generally laid out. There is nothing the toolkit – any tool kit – can do to change the layout from say KDE’s System Settings to be Microsoft’s Control Panel. That’s well beyond the scope of the toolkit.
However, the toolkit can ensure that the various controls provided – buttons, list boxes, combo boxes, etc – look and behave the same as those of the native platform the software is running on.
It has nothing to do with Qt/KDE Apps or GTK apps. It has everything to do with the controls the displayed to the user and ensuring they look and behave the same way.
The toolkit does not the application make. It just provides the framework for the application to be built with.
If you want to take up differences between applications, then talk to the developers of those applications, not the developers of the toolkits of which they use.
I think you missed the point of the whole project.
The toolkit is not the focus here. It’s not very hard to create an application that looks like it is native, where my buttons look like everyone else’s buttons. Anyone with access to Qt can do that.
The reason why I am focusing on the DE and not the toolkit is because the aim is to make the app feel like it is part of the DE.
I will give you an example of that feeling.
The average user doesn’t know what “Windows Explorer” is. Some of the more tech savvy ones will suspect it has something to do with that blue e. But if you tell them to open “My Documents” they will all know how to do that. Explorer is so integrated into their experience that they can focus entirely on the content instead of the actual application.
I want to remove the application from the music experience. Why do you think I have silent upgrades, an automatic scanner, no need for codec installation, instant streaming from YouTube, and so on. I want to put the focus on the content, and I want to do that in an integrated and seamless way.
You can’t remove the focus on your application if you look like Winamp. That’s like saying “don’t mind me” while putting a stick into someone’s eyes.
You are talking apples and oranges
You missing the point on why there are different DEs out there. Not everyone want something like Windows.
And interestingly enough, a lot of what Apple and Microsoft are currently doing with Mac OSX/iOS and Windows was done by KDE before they got there.
For example, put KDE4 into Netbook mode and then compare it to iOS or Windows Phone 7 or Windows 8. Or put KDE4 into Desktop mode and compare it Vista and Win7. Please note that KDE was doing that stuff before Vista was around – before any betas were released.
The only way you can get an app to feel as if it is part of a specific DE is if it is written with the design goals of that DE. Doesn’t matter whether you are targetting Windows, Mac, iOS, KDE, GNOME, XFCE, LXE, or any other DE – it just doesn’t work. They all have different goals or mixtures of goals – and are not compatible. The people behind them also have no interest in doing what the others do – they set out to make their DE the way they wanted it, and they have large groups of users that like it that way.
If you want Windows, then use Windows. You are not going to get Apple to make Mac OSX look and feel like Windows – which is probably an easier task than getting KDE or GNOME or XFCE or LXE or … to do that as well. Yes, KDE and GNOME have historically provided some Skins that enable it to mimic the Windows look like you are noting – but this is primarily down to theming of the colors – it never involves moving around the widgets in the display, or changing the System Settings to look like Control Panel; though it might provide a similar looking desktop – though even there the names would be different, but the icons would be themed close enough to help the user out.
Now you are talking something else entirely.
Codecs will always be required. Whether you use Windows or Mac or Linux or BSD or whatever. The default – as with Windows and Mac – might cover most of the commercial players out there; but they still won’t be complete. Sadly, Linux distros typically lack most of those same defaults but that is primarily due to licensing issues.
Automatic hardware detection is also not part of the DE – its part of the underlying hardware abstraction layer (HAL), and having drivers that support it. Until all the hardware manufacturers start delivering drivers and working with the community to support Linux, that simply won’t happen. They are slowly coming around, but they are primarily focused on Windows. As the markets reorder themselves over the next 5-10 years (in which Windows will become less and less of a player) then that will change on its own too.
Again, you’re on apples and oranges.
Putting a face on the content is one thing. But that has little to nothing to do with the DE. In fact, KDE4 is probably more oriented to what you want to do that way than any other DE out there – and yes, you can put it on Windows too – even eventually replace the Windows shell with the KDE4 Plasma shell. (Check out windows.kde.org).
Making all the DEs look and work the same way is not going to do what you want.
Rather, you need an application with sufficient support to do that, and you have to drive usage of that application. Nothing else will really do that.
Here’s the thing – if you want people to use your application; then you need them to know they are using it and want to use it.
People use Windows primarily because it is ubiquitous on all PCs from the store. They feel the don’t have a choice for the most part, and are too lazy to change it – after all they paid for it when they bought the computer, and that’s what the manufacturer put on there to it must work best on the computer, right? (No, but that’s a whole different issue.)
As a result, while people may use Windows Explorer or Notepad or Word or Excel, it’s not because they think they are using Word or Excel – but because they think they are using Windows and Office, and that’s what everyone else uses so why shouldn’t they?
People use Mac OSX because they want to use Mac OSX.
People use Linux and KDE because they want to use Linux and KDE (Or GNOME or XFCE or LXE etc.). They consciously choose to use those.
Likewise, people use WinAmp or RealPlayer or iTunes specifically to use those – they conscientiously do so.
Developers of commercial applications (e.g. Adobe Acrobat, Photoshop; IBM Symphony, WebSphere, etc.) need those applications to stand out so that they can make money.
Developers of FOSS software need them to stand out to draw users – the specific users they want to draw.
In both cases, those applications will highlight the content as well – that’s what drives the application. But the application is going to stand out too – to drive users of that content to use that application because it can do some feature better than other similar applications or make it easier, more intuitive to the user.
And, believe it or not, not everyone thinks alike. So some methods of doing things make better sense to some people than others. The DEs and applications target those differences.
So, while what you are setting out to achieve is admirable; it is also 100% impossible to do as it would require that everyone think like you to be successful, which obviously we do not – for numerous reasons (how our brains are wired, culture, experiences, beliefs, etc.)
What? I wrote the article. I am the one who choose what to write about. Can you please specify what the apples are and what the oranges are. In my view you are talking about apples and I was trying to get a conversation going about oranges. So maybe we could skip the apples?
Exactly. So that’s why I will make my Mac OS X version completely different from my Windows version. Because the Mac people don’t want the same things out of their music experience as the Windows people do.
Which is why I will make each version different. I am not trying to make ONE version for all environments, but instead several versions, one for EACH environment.
Why on earth would I want to force my Mac users to have a Windows experience? That’s exactly the thing I am trying to avoid. That the whole issue I have with ports. That’s why I don’t like running iTunes or Spotify on Windows, because you KNOW that they were written by Mac people for Mac people first. That’s why I don’t like Skype on Linux.
Again, you are totally missing my point. I am trying to get away from the thing you are warning about.
No, this is what I have been trying to convey the whole time. I think this is a case of some serious miscommunication. This is my point. This is my goal. This is my focus!
Yes, but I don’t want the user to be required to care about that. I want to distribute the codecs with my application. So when I say “no need for codec installation” I mean it as a separate action performed by the user. Think of how VLC works for example. You install it and you get all codecs built in needed to play almost any file you throw at it.
Now were are getting down to technical stuff. In this article I am trying to focus on what the user perceives. The actual solution to solve the problems may be found in using tools provided by the DE, the toolkit or the TCP stack. In this article I am trying to focus on the user their experience. And the user doesn’t necessarily know what the difference between the OS and the DE is. The DE is the environment in which the user resides, the layers behind the DE is not usually exposed to the user.
Oh, and please note that geeks and nerds are not the focus on this particular article. I could write a whole other article on stuff aimed for them, but not today.
I am not trying to change the DE in any way. I am trying to make my app feel like a part of the DE by adapting my app to the different DEs. So my KDE version will be specifically aimed at KDE and be extremely integrated with KDE, using all the tools KDE provide, behave in a way consistent with the way KDE and its apps behave. The Gnome version of my app will be something entirely different.
I don’t agree. I think you can brand stuff my removing the brand. At least to the degree where people won’t be annoyed. It still has a name, it still has a website, there is still a brand. But you can create a brand and make people associate it with “staying out of your face and letting you focus on what you want to do”. When you feel like playing music you don’t want a popup telling you that you should upgrade. And you don’t want a dialog telling you that you are missing a dialog. That’s what I mean when I say that I want to put the focus on the content instead of the application.
It’s not impossible.
See the rest of my comment. You are getting mixed up what is whose responsibility and how much control anyone has over that.
And just because your wrote TFA doesn’t mean you’re not off-base.
Exactly. So that’s why I will make my Mac OS X version completely different from my Windows version. [/q]
See below.
Which is why I will make each version different. I am not trying to make ONE version for all environments, but instead several versions, one for EACH environment. [/q]
Again, see below.
Why on earth would I want to force my Mac users to have a Windows experience? That’s exactly the thing I am trying to avoid. That the whole issue I have with ports. That’s why I don’t like running iTunes or Spotify on Windows, because you KNOW that they were written by Mac people for Mac people first. That’s why I don’t like Skype on Linux.
Again, you are totally missing my point. I am trying to get away from the thing you are warning about. [/q]
Now you are getting into a whole different issue, and you need to make a business case for it, not simply say this is what programmers ought to be doing.
Is there a business case for applications to be more integrated into each DE/OS than a multi-platform toolkit would allow?
FYI – the reason businesses and FLOSS projects uses multi-platform toolkits is to minimize costs. What you are talking about would only increase costs as it de facto increases the code base. With an increase in code base means an increase in bugs and programmers, and documentation, etc.
Businesses won’t do that. That why you see applications like TeamViewer use Wine to support Linux. Or applications like Cisco VPN use WxWidgets, or AutoDesk and Maya use Qt.
So you’re chasing your tail there, as companies won’t do it. And you can expect even less support from the FLOSS community as they are just as concerned about what they have to support in that respect; so unless you’re going to multiple yourself 1000’s of times over, and do the work for every project you again chasing your tail.
No, this is what I have been trying to convey the whole time. [/q]
Okay – but you led off on numerous rabbit trails (e.g. ranting against toolkits) to get there.
FYI – VLC does not come with all the codecs. They do have a good number; but they also rely on the codecs that are installed on the system already.
Also, go ahead and distribute the codecs with your application. Just don’t complain when the MPEG-LA comes knocking at your door for a very expensive license for the MPEG, AACS, and nearly all other proprietary codecs. (FYI – Microsoft and Apple both belong to MPEG-LA.) Can you stay in business?
Agreed that most users – Windows and Mac users – don’t understand the difference between OS and DE. But that doesn’t change where the responsibility lies for the support, or who has to contribute to make it work.
The Linux community would gladly welcome hardware manufacturers to join in, provide specifications or even hands to support their hardware. Sadly, too many think their custom drivers and firmware are what sets them apart, or don’t think there’s a market, or that it’s too hard to support.
As I said, you need to be writing to the business users – InfoWorld, etc. Talk to the CEOs, etc. Writing to OSAlert won’t get you there – you’re solely talking to geeks.
I am not trying to change the DE in any way. I am trying to make my app feel like a part of the DE by adapting my app to the different DEs. So my KDE version will be specifically aimed at KDE and be extremely integrated with KDE, using all the tools KDE provide, behave in a way consistent with the way KDE and its apps behave. The Gnome version of my app will be something entirely different. [/q]
So you’re going to use Qt for KDE, and Gtk for GNOME, and MFC/.Net/WinRT for Windows, and Cocoa on Mac?
Again, you’re talking orthogonal approaches to software, completely different programming languages (C++, Objective C, C#, HTML5), and code bases. You’ve now dramatically increased your cost and man hours, time to market, etc.
I don’t agree. I think you can brand stuff my removing the brand. At least to the degree where people won’t be annoyed….When you feel like playing music you don’t want a popup telling you that you should upgrade. And you don’t want a dialog telling you that you are missing a dialog. That’s what I mean when I say that I want to put the focus on the content instead of the application. [/q]
The pop-up thing has nothing to do with the DE/OS or integration. It has to do with ensuring software is up-to-date, and (for commercial software) selling upgrades. For FLOSS, it’s about getting users to use the latest stuff with the least number of bugs that is most supportable; and those things are optional. For commercial software, it’s about money – and sometimes they are optional, often they are not. But you won’t get them to get rid of it because it’s about money.
Try to find a business case and you’ll see.
I am writing this from my phone so I’ll keep it short.
There are some key points I want to make. First, I am not here to convince other people to follow my lead. I am here to get input from people using these environments. This is about my project and not about changing other projects.
Secondly, my examples about popups and such were ment to illustrate my overall goal, to give my integration focus a sort of context.
Your posts seem to indicate otherwise.
That’s unfortunate. I thought the article was focused enough on why I am aiming for this, that it is focused on my project, and lastly what kind of input I am after. Each section corresponds respectively.
But hopefully this thread has cleared up things a bit.
I was mostly talking about your comment posts in the various threads; though reviewing your article closer, you only make one mention of your project (in the section appropriately named); the rest seems focused on HMI/HCI in general terms; not really relating to simply your project but lambasting everyone.
For example:
Your line about your project makes it seem like your setting the example for everyone to follow:
If you really want to write up a good article asking for help in making your project accomplish those goals, then don’t be shy about talking about your project, the challenges you know of, etc. As it is, TFA is too general, and the comments in the various threads don’t necessarily always help that focus.
For example, look at how this thread started off – a blasting about how toolkits are bad (admittedly not totally you, but you kept on the same line of argument for a long time despite that not being your goal, or necessarily your view).
Thanks for the pointers.
I really had a problem with the discussion steering off in the direction of toolkit bashing. My comments were an effort to direct it back but I seemed to have failed.
I guess I was too afraid of making the article seem like one big spam article advertising for my pet project. I wanted the focus to be more on how to make an interface native for Mac, KDE, Gnome, etc. What makes a port feel like a port even if it “looks” native on the surface. What are the details that can’t be found in the HIGs. What are the key features of the OS/DE that I should leverage.
I seemed to have failed in getting answers to those questions but I have learned a lot of other things. So it ain’t all bad.
Besides, I got one donation and a new programmer. Always a plus.
I had a number of similar failures early on as I learned how to communicate. So long as you learn from your mistakes…
It’s a matter of presentation.
For example, you can use the project as an example (which is what seems to have been the case, though unintended) or you can use it to ask the questions, e.g. the following:
Project X does A and so should everyone.
Project Y is looking to do Z; and has components D,E,L,T, and A. What is the best way to do that? Should we utilize E with H? Can L be integrated with P?
Learning it the key. Repeating the same mistakes will only drive people away; and learning how to communicate is a very large thing – which is the important thing. If you can’t communicate, then you can’t ask the right question or drive the topic in desired direction; though you might get some that may follow where you want to go, most probably will not.
Agreed.
The makers of Qt go to great length to make sure that the QWidget set is native look and feel. Sadly, they are not doing that at all with the QML set – which ignores native look’n feel altogether and goes for same look’n feel on all platforms.
However, as Qt shows with QtGUI/QWidget, a properly designed toolkit can indeed provide just as good a native look’n feel as the native APIs. (And Qt even does it without using the native widgets on Windows!)
In some cases you get better tools too. GUI programming on Windows is a PITA, especially if you want to use the same controls as Microsoft – since they don’t typically release those controls right away, and many require a lot of extra work to do the same way.
I fully agree on this one. This project was my first endeavor with Windows programming and it is really annoying that Microsoft has created this Aero theme that I actually like but they don’t give it to us developers.
On the other hand, Qt is one of the greatest toolkits (really not fair, its actually a lot more than that) I’ve ever worked with. I haven’t that much experience with GTK+ but I created a few Qt3 apps for KDE back before I switched to Win7 and it was so easy and the API is very well documented.
They have a long history of that.
For example, they typically will display controls in their products – e.g. the Ribbon UI – long before they ever release a control to the general developer use. That’s understandable while in beta and getting the bugs out; but once they release it for general use in their own programs it should also be available to everyone else.
Good examples of this are: Ribbon UI, Indeterminate Progress Bars, text on top of progress bars, various menus and tool bar styles they have done over the years.
Windows, Office, and Visual Studios usually get these things first; and then on a rare occasion they release it to the wild.
On a past commercial project, I had one guy help me on and he added a very practical function to the GUI; but he had to do a lot of custom (Win32+MFC) work to do it – and all he did was enable us to have a line editor and combo box mixed together so we could have some custom editing functionality in the combo box (e.g. for a remote file path structure); even though he had done it before it took him a couple days to do. (Even though I know what he did, it’d probably take me a week to do now still.) Yet these are controls that Microsoft uses regularly in their system.
They did a great job designing it and have continuously updated it with new technologies and features; not to mention they pioneered a few features too.
Gtk+ followed MFC style too much. WxWidgets does both, but as a result has its own idiosyncrasies. There’s not much else out there that is truly platform independent and performant at the same time.
My personal favorite Mac app UI at the moment is Sparrow (http://sparrowmailapp.com/), and I would love to see a music player that looks like that.
Of course, that is arguably not “native” looking, but then again, Apple loves breaking their own rules.
Gnome have their own guidelines: for older Gnome 2: http://developer.gnome.org/hig-book/3.0/ and for new Gnome 3 – http://live.gnome.org/GnomeShell/Design/Guidelines
A better and more general page would be: https://live.gnome.org/Design
and for apps
https://live.gnome.org/Design/Apps
For a music / media player:
https://live.gnome.org/Design/Apps/Music
Even more (recent) mockups can be found on https://github.com/gnome-design-team/gnome-mockups
Note that new GNome design seems to break radically with older implementations (Banshee, Rhythmbox, …), and other OSes.
Thanks. Reading the HIG would be step one, of course. I was really looking for some tips that may not be so easily found in written guidelines. The kind of tips you only get after really using a system for a prolonged period of time.
GNUStep allows you to write Cocoa apps on OS X and simply recompile them for Linux. The Linux version will look old and gray, but that’s actually kinda what “native” looks like on X11 systems.
I’m not sure GNUstep is entirely Cocoa compliant, but you probably could compile most GNUstep apps under Cocoa. Then again, hardly anyone uses GNUstep, so most users would avoid an application that depends on yet another library. Just installing GNUstep’s Minesweeper clone takes almost 50 MB because of that, and it behaves like a true alien under KDE, with its own desktop menus and dock icons.
So yeah, it’s native and ugly under Linux, but also brings along with it parts of the Nextstep desktop. It might be interesting to try it under Windowmaker, but who uses that nowadays?
I do. I kinda oscillate between Window Maker, StumpWM, and GNOME, depending on the system specs and my mood.
Cool. Maybe you can tell me some of the differences between those environments?
I should restate my goal with this project: I want Stoffi to feel like it’s a part of Window Maker, StumpWM and Gnome (3, to start with). And that may (most likely) require me to write one interface for each environment.
But let’s assume there was one version of Stoffi for each of these environments and it was designed so awesomely that it felt like it was actually a part of the DE. How would that look, how would it behave and how would it differ to the other Stoffi versions?
StumpWM has absolutely nothing. No borders, no titles, no themes, not even a background by default. There’s no such thing as native. GNUStep doesn’t really have any themeability, and there’s no coherent guidelines I’m aware of. Just use the GNUStep framework and you’ll be fine. GNOME 3? Just use Gtk+, whether 2.x or 3.x, and you’re good. Thing is, on Linux pretty much everyone has Firefox or Chromium installed, and both of those use Gtk+ 2.x. Unless they’re using KDE (and even if they are, there’s a Gtk+2 theme engine to mimic Oxygen), Gtk+ is the de facto native toolkit for Linux. I’m not familiar with Gtk on OS X, but if there were a way to get it to use Cocoa, that could be the solution to your problem.
StumpWM sounds really interesting. I think I might check it out and learn more.
I will most probably go with GTK first on Linux since their C# bindings are very well supported. I think the GTK theme can be reused on many DEs other than Gnome so that would be a huge win.
On KDE I’m not sure but maybe Qyoto or some similar bindings will be better established in the future.
On Mac there’s always MonoMac which provides access to Cocoa# which is great.
With ~A‰toil~A(c) GNUStep looks nice…
http://etoileos.com/
Another good option is wxWidgets, it allows a real nice native touch after more than 10 years of improvements.
I’m not sure of the progress of these efforts, but a GNOME theme was working but unfinished on GNUstep somewhat recently:
http://heronsperch.blogspot.com/2010/12/bean-running-with-gnome-nat…
http://heronsperch.blogspot.com/2011/01/how-to-build-gnome-theme.ht…
There are a couple other posts about this on that blog, which is written by the maintainer of GNUstep, Gregory John Casamento.
More on GNUstep themes:
http://wiki.gnustep.org/index.php/Themes
Your best bet for current information is the mailing lists:
http://wiki.gnustep.org/index.php/Get_Help
Edited 2012-01-24 05:57 UTC
It might be a good idea to separate the application into a client and a server. The server contains platform-independent code and implements the business logic of the application. The client contains platform-specific code and implements the user interface.
This way you have a clean separation between the UI and the rest of the code, and adding new UIs (or CLIs) will be relatively easy and can be completely “native”.
This is exactly what I’ve done actually. Instead I call it Core (since I have a server part for the cloud platform so not to mix those parts up).
My aim is to keep the Core and just write a new GUI for each supported platform. Maybe even write a Fluxbox interface to make it melt in perfectly with Fluxbox (that would be sooo awesome!).
For a good GNOME/GTK+ UI I think you should have a look at the mock ups by the GNOME project that have been mentioned earlier and you should also check out the elementary project elementaryos.org. Good luck with your application btw, look forward to seeing in on my Mac/Ubuntu dualboot
I agree entirely with what the author is trying to achieve here. Nothing peeves me more than an inconsistent look and feel to a user interface.
Media players and soft VoIP clients are the worst offenders. Why they feel the need to reinvent the wheel, I’ve no idea. Having said that, I do think the author has a massive challenge ahead, after all, Microsoft themselves provide different libraries (winforms, MFC, WPF, etc) that all give different results. Look at some of their own products too, Office, Media Player, there’s no consistency.
I’d be interested to see how the Windows app (in the screenshot) looks on Windows XP, as I’d imagine it looks very much out of place. What about on Windows 7 with Aero disabled?
Tough challenge, but I wish you well.
Also, respect the target platform’s way of working. e.g. On Linux, store user data under $HOME, on Windows, use the APIs to get the correct locations, *don’t* store them in the Program Files directory or in a directory off the root of the system drive. Ensure your software runs completely without administrator rights (with exception to the installer). Ensure your software works in different environments (e.g. does it work when folder redirection/roaming profiles is enabled in a corporate environment). Use an installer that is easy for end users to install your software, but also powerful enough to allow automated mass deployment to an entire network of computers (using standard existing deployment techniques). Honour other system wide/user settings, e.g. font sizes/colours.
Edited 2012-01-23 15:05 UTC
Thanks for the kind words!
For the stuff about Microsoft: I know! I am using WPF and I have styled it EXTREMELY to get a good looking feel of the interface. The standard WPF theme is awful.
As for the challenges: that’s why I’m doing this.
And lastly, of course it’s not only about the look. But about installation procedures, file structure layout, etc, etc. I want the user to believe that Stoffi exists for his/her platform only (or at least was developed for it first).
Each user should get the impression that the application was designed for his operating system only.
I can only see this happening if the front end (GUI) is specifically rewritten for every DE this application targets. Which might entail Windows, Mac OS X, KDE 3 (Trinity?) & 4, Gnome 2 & 3, Unity, Cinnamon, XFCE 4.x, LXDE, Razor-QT, WindowMaker, FVWM, etc. Quite a tall order.
Or give it a distinct look and feel which doesn’t follow UI conventions on any platform, but makes it equally non-native on each platform, but also universally consistent in its own UI. Seemed to have worked for WinAMP.
Well the title had to be short but really I’m not looking for a single interface for Linux. I aim at doing an interface for each environment. It would be really awesome to have Stoffi featuring a Fluxbox interface for the three guys using it, making them go “woooow” over how awesome it looks for them.
I think I would start with Gnome and KDE and them move down the list in popularity order as long as I can.
So that’s why I need your help. There’s so many environments and I have not even used some (or even heard of some). So your input on what makes LXDE shine and how to make an app native to that environment will be essential for me when doing the LXDE interface.
It must be joke to ask for native look&feel for Linux. Putting aside things like Gnome vs KDE, and diffident distributions they are changing so dramatic now. I’m using Lunux for last 6-7 years everyday, and still I’m not able to use Gnome3 or Unity on Ubuntu – same window manager and same distribution I use science 5 years…
Soon Win8 will be probably so different form Win7 as Win7 is to WinXP.
Mac is probably more conservative, but still they are changing UI.
If people who make this “native” look&feels don’t care why do you?
I think your UI should be so easy that my son, who use mostly iOS or Android, could also use your application on FreeBSD even if he see this OS for a first time in his life.
Who is your main user? Someone who spend last 10 years on front of the same computer? If not what is native for him – not for OS he just happen to use today.
Since “Linux” contains several environments and several GUIs I will make an interface for each environment (going as far as I can, since it will be nearly impossible to cover them all).
That’s the reason for asking the community. Let me know how you think an “native” app should look in *your* environment (even if it’s Blackbox, Haiku or something else) and I will keep it in mind when I create that particular interface.
There is no such thing as a native UI for Linux because Linux has nothing to do with UI. As a kernel, it really only functions as a part of what you could see as a complete operating system.
If you want to have a native UI then you have to focus on the platform used for the UI, not just some kernel. Popular desktops that are used in combination with the Linux kernel on a GNU system are KDE and Gnome. I use Trinity. These desktops can work with different types of underlying operating systems, which may be interesting to support as well.
Good luck!
Instead of repeating myself too much I will refer you to the answer I gave to the poster above you. In short: my aim is one interface for each environment. So tell me what you use and how it should look and work there.
I use the Trinity Desktop Environment, which is basically a branch of an old version of KDE (version 3.5). You can find information about it here:
http://www.trinitydesktop.org/
It is not shipped with any major GNU/Linux distribution (anymore/yet) and most people will consider its components outdated. It is still being used in many large scale desktop deployments however.
To get a fully native application for this environment, you would have to have it compile against all the outdated libraries that this desktop environment depends on. (Qt3 and kdelibs version 3.5.)
Because normally few people are going to develop their applications against these old libraries, right now there are development efforts from the Trinity side to get GTK and Qt4 applications to at least look as native. Using one of those two toolkits would be the safest.
I guess you already want to develop both a version targeted towards KDE 4 and a version for Gnome, so one of these versions should be relatively ok for Trinity as well. If you really do not want a to stand out at all, you will have to have a version that compiles against the Trinity libraries. Then it would be perfect for my environment.
Let’s assume there will be only one version of Stoffi: A Trinity version. Let’s also assume that I will be able to find out myself where to use drop shadows, the fonts to use, button gradients and so on. What other things should I consider? Do you have tips on some applications on Trinity from where I should draw inspiration? Should I go for a menubar or not? Should I keep the current layout (left=navigation, top=playback, bottom=information, right=content) or should it be something else? What should happen when you press minimize or close? Should it close to tray or not? How should preferences be structured? If there will be a menu how should it be organized?
These are the smaller details that I think are absolutely necessary to consider when trying to make a version of Stoffi that feels like it’s actually a part of Trinity and not a third party application.
I guess you could look at the Trinity version of Amarok to find most inspiration for your application.
Your layout seems ok to me, but for me, any layout would feel equally native to me. It’s the appearance of the widgets and the speed of the overall application that would make the difference.
I guess minimize should minimize to the taskbar and close should be configurable to either close or still keep it running in the system tray (that would be the default action). This is how other programs have it in Trinity.
For a native Trinity application, there will almost always be the possibility to have a menu-bar, but it can also be turned off. In addition there is a configurable toolbar (large/small icons, text/no-text, button layout, etc.). It depends on whether your application really works easier with a menu bar whether it’s enabled or not by default (in most cases yes, only a few no).
…use a wrapper (one is probably available already, or not even necessary these days, I don’t know) so that the app fits in both KDE and GNOME environments.
I like your Windows app! Looks good. I hope you can use the same/similar ideas for Linux and Mac OS X. No reason why you couldn’t do it.
Nice! I downloaded and donated.
Awesome! Thank you so much. And congratulations: you are the first donor! I wish more people were like you *hint*
I hope more do, too.
It appears you have successfully creating something that looks like Windows.
Port the design directly to OSX and it will fit in fine. Obviously Linux desktop environments are a mess.
You may be missing the bigger, better, newer picture though: Windows Metro, Android 4, iOS.
Oh, I really look forward to doing the Metro interface of Stoffi, and the one for iOS and Android. We have an upcoming remote control for iOS so we have something to start with there at least. But I really look forward to playing with the Metro stuff.
If you don’t want to do all the work porting across the different Linux/UNIX/BSD flavors, you might want to look in to wxWidgets, if I remember correctly it just tries to wrap native widgets in to a slightly more strict framework so it can work on most systems. I’ve used it in the past for making things just work across platforms. Because of that you can’t do much that is fancy, but it looks like you don’t want to anyway being that you want something that looks native rather than shiny.
But “porting” is what I want to do!
I have built the whole project to have the whole interface easily replaced just so I can create one for each environment.
Take a look at the Mac OS X Human Interface Guidelines: http://developer.apple.com/library/mac/#documentation/UserExperienc…
They are very detailed and even interesting for a non-Mac OS X user.
The best way is to modularize your application.
Separate the core logic from the UI and system specific code.
This way you can recode the UI to the specific OS while keeping the same application logic.
At the same type the system specific abstractions allow your code to be independent of the way the OS handles things like user preferences, for example.
The problem with most toolkits is that they fail most of the time either on the look or the feel from the OS, forcing the developer to spend quite some time making the application feel really native.
On the other hand it is always a question of ROI.
*cough* Gang of Four *cough*
That’s what I’ve done. I will be able to use my “Core” on a lot of platforms thanks to Mono. Now I am in the process of doing *all* the other interfaces and that’s why I need suggestions on how to make them look and work the best way they can for their respective environment (such as Mac OS X, KDE, Gnome, LXDE, XFCE, Fluxbox, etc). I will skip old stuff and only go for new versions initially (just as I skipped XP and Vista and went for 7 on Windows), so I may not do a KDE 3 interface for example.
This is a blog post I read a while ago. Take it with a grain of salt as I don’t think they have a Linux client yet.
http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-write-cros…
I have my project divided into two parts: GUI and Core. The core is cross platform and the GUI will be one for each environment: KDE, Gnome, Mac, Windows 7, Metro, etc, etc.
So I need suggestions on what to aim for when making the different interfaces. What should the Fluxbox interface look like and how should it behave to make it feel really, really, really consistent with the rest of the system, for example?
Making a native-looking Linux app might be hard, but making a KDE4 app isn’t, really: There is a fairly coherent visual style, and just writing the GUI with the appropriate classes will get him decently close.
There will be a KDE 4 interface (aimed for and available only on KDE 4). My question to all KDE 4 users is: what should that interface look like and work like to make you believe that this is actually a part of KDE 4? The kind of input I won’t get by reading the HIGs and similar GUI related guidelines.
For Unix-like systems you should have two versions: on for KDE4 and another for GNOME3. Installing full versions of these environments will give the idea of how the app for each of them should look like. In GNOME’s case looking at design wiki would also be useful, as this environment is currently in transition. The rest of WM/DE landscape members are not attempting at consistency, so they are not your target auditory.
Yeah, I will start with Gnome and KDE (perhaps also a Unity interface). But it would be really awesome to also integrate with E17 for example and other exotic environments.
It’s easy for me to look at these environments and try to mimic them but I know that for an application to actually feel like it’s a part of the environment one needs to heavily use it for an extended period of time, to really learn those small details.
In short, I want tips on how I should make my KDE 4 version feel like a part of KDE 4 and not a third party application. Since I haven’t used KDE 4 much I need tips from users of KDE 4. I need the dream interface, the vision.
E17 would be fine, but it isn’t ready yet, so you may come back to it later. Still, I’m not quite sure they offer some substantial degree of consistency anyway, so you can target a generic idea of lightweight UI for E17, FXCE and WMs with no DEs to establish consistent look and feel.
Yeah, that is more of a “it would be cool to do sometime in the future if I ever get the time”. The initial focus will be on Mac, Gnome and KDE in that order. Than perhaps move to other DEs but probably not before I also have made an iOS, Android and Metro interface.
Interestingly Android will present somewhat similar issues as Linux does. There are several “environments” on Android like TouchWiz and Sense along with the “native” interface. If I want my app to blend in there there may have to be some considerations to those differences as well, even if it may be only “look” and not really any “feel” differences, allowing me to create a single interface and just skinning it basically.
I suggest using simply because it’s able to create an almost native look on almost any platform. For example, it’s uses the global menu on Mac OS X and Unity (patches merged in 4.8) and inherits the GTK theme when using a GTK desktop environment.
One of the best examples of showing the native looks of a Qt4 application on any platform would probably be VirtualBox.
On Mac OS X:
http://mac.appstorm.net/wp-content/uploads/2009/02/03_4_guest_addit…
http://static.arstechnica.com/1-failedunmount.jpg
http://img.skitch.com/20080903-rgadw7bh3w8ynjwcsttxu8p8dq.jpg
You can see how the gradients, buttons, dialog boxes, tabs, etc. all look consistent with other Mac applications.
On KDE and GNOME/Unity:
http://www.freetechie.com/gallery/albums/userpics/10001/Tabbed_Wind…
http://i.imgur.com/4n6AT.jpg
You can see how VirtualBox integrates into the desktop environments and how it uses the native GTK file selection dialog when used on GNOME.
—-
When you selecting your toolkit, I think you should find one that “fits” in your existing code. Since Stoffi was written in C#, you should find a toolkit that has bindings in C#.
Qt has C#/.NET bindings for all of its modules (https://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings). There’s also GTK# if you decide to use GTK. Many people in the previous comments have recommended wxWidgets, but they do not (at least officially) have C# bindings.
Hope this helps
VirtualBox is actually also a good example of the negative sides of relying on a cross platform toolkit: while it draws the widgets using native routines, the layout of the widget does not conform to the UI guidelines. Mac OS X specifies a certain distance that widgets are supposed to keep from window borders and other widgets. Qt or wxWidgets do not enforce these distances, nor do they enforce the default type faces or sizes.
By violating the layout guidelines, an application can draw using native widgets but still look alien to a Mac user.
Ok, there’s been several comments mentioning Qt4 and WxWidgets (both of which I’ve used before but only very, very, very briefly in other projects). However, I need to know what the drawbacks are when compared to making one interface for each environment (KDE, Gnome, Unity, LXDE, etc). What do I gain by going that route instead of opting for a “one toolkit to rule them all”? What are the drawbacks on Qt4 vs WxWidgets?
I have no idea what you mean by native opensource/linux. What IS interesting though, is if you interpret this statement to mean, making the OS act as if it talks directly to the hardware. And you can do that, alteast on Linux.
Ofcourse that is problaby not what you mean, and you might be looking for art.gnome.org
Much excellent art there, and I think Ubuntu picked up some of the most popular trends.
Now though, if you want to experience the reason why some people still swear to machines like Amiga, C64 and possibly other platforms that talked directly to the hardware (arcades, etc) you need to configure linux for the lowest possible latency.
Now that is what I call “native”. As if things were written in native ASM.
I`ve been working on a MAC with windows lately unfortunatley so this config for a few kernels back will have to do.
http://paradoxuncreated.com/tmp/.config39
That was specifically tailored for my machine, so you need to just look at the hardware unspecifics there.
It`s really just about avoiding more complicated processes, to reduce latency, and favor processes of lower latency, and favor them throughout the config.
Stuff like demos etc, will run like on Amiga without interruption, (on most modern PC hardware I guess)
I can get sound in renoise down to 0.33 ms latency with my professional tc electronics soundcard etc.
I also tweaked a doom3 config to run extremely smooth. Arcade style.
Now THAT would be native
Not to speak about how responsive the desktop gets. You might need to do a few more tweaks, for maximal response here and there too, but I am sure you are expert osnews-readers, and all this is lame to you (not).
Well I’m not talking about native code but instead of native perception from the user. That is: I want the user to think my application is part of his/her system.
I think this endeavor is big enough. Writing assembly code for each platform and each processor (of course there should be a Solaris version of Stoffi so I can run in on my universities lab computers) will be huge to say the least. Maybe when I retire…
Maybe I’m not enough of an Interface Geek, but I don’t get it. I don’t think there is a Perfect interface that everyone would love. If there is, I highly doubt that its going to be found by first trying to make it perfectly consistent with a particular Gui’s look and feel. I guess I’m not am not a true UI believer.
Music players that blend perfectly into KDE or GNOME already exist.
I don’t understand its reason to exist on Linux. But, obviously, you use GTK for Gnome or QT for KDE. I prefer the C++ approach of qt coding, but visually either one is okay.
No, there is absolutely no “perfect” interface. So that’s why I will create one interface for each environment. I will create one for KDE and one for Gnome. There will be one interface for Windows 7 and a whole other one for Windows 8 with Metro. And so on…
That’s why I have made the architecture choice I have made and made it really easy to swap out the whole interface but keep the core cross platform.
Interesting. Not really what I meant in my head, but re reading it I completely understand your interpretation of it and makes a lot more sense then my own.
I was more or less talking about consistency within a given Desktop Environment. I don’t think it makes sense to make a music play display music similarly to how windows explorer displays files.
Interesting. But that makes my question even more relevant: what would YOUR dream interface on YOUR system look like and behave like?
ephracis,
“But that makes my question even more relevant: what would YOUR dream interface on YOUR system look like and behave like?”
There was once a time I would spend a great deal of time tweaking my desktop to individualize it to my personal tastes, but I no longer find it worthwhile to do so. I’m more interested in applications that just work well.
For example, I use wireshark because it works great. I’m comparing it to other apps right now, and I’m noticing differences I never noticed before. Rather different handling of alt-keys, different menu fonts, but I honestly never even noticed those before because it’s not all that important to me.
On the other hand, I’ve seen some rather stupid themed apps that not only look out of place, but they can actually get in the way of usability which really bothers me. Examples of these are certain anti-virus tools and my motherboard tuning utility which is in the shape of an animated car engine that displays on every boot (shame on you gigabyte). Not only are they ugly, unprofessional, and out of place, but they’re also unnecessarily difficult to use.
As far as I’m concerned, just keep your design sensible, and that’s good enough for me on any platform. I would say to focus more on how well it works than how it looks, although frankly that seems to be the opposite of what everyone else is doing.
Edited 2012-01-24 00:02 UTC
You bring up some very interesting points. When I talk about interface design I think of more than just the graphics. The way something behaves or how it is placed is also an important part of the interface.
If you would imagine that you run Stoffi but you didn’t know it, because you thought it was part of the DE you were running, how would that be? Everything from keyboard shortcuts to menu layout.
I will probably not need much help with choosing the font and whether or not to have a drop shadow on my context menus. I will just look at the DE and choose to follow their lead on that. What I need help with are the smaller details, the one that only true and heavy users will notice (like handling of alt-keys).
ephracis,
A pragmatic question here…it sounds like you are aiming to build many localized versions for most/all desktop environments. Will you have one *nix version which auto-detects the desktop environment and changes it’s engine accordingly? Or will you have many different downloads? Too many choices could be confusing for users, and users might end up with the “wrong” one.
Are you going to have a bitmap theming system? Or are you building native controls using the native toolkits?
There are pros and cons of each.
Using native controls, most of the control’s visual & interactive functionality will automatically adapt to the host’s defaults.
However if you ever plan to incorporate a theming system that allows end user’s to change their theme using bitmaps (aka winamp), then don’t expect the native controls on each platform to support it in a compatible way. You could always make a separate version where you render your own components, but that’s a heavy maintenance burden in my opinion.
First of all, there will probably be different downloads but with an auto detect feature on the web server. A lot of my current users are very conscious about download size and so having a KDE user download the Gnome interface but never use it will increase the download size without any benefits.
The problem will be doing the auto detection. I will probably go for a “best effort” approach and then leave the user with the possibility to correct my guess or make the final choice.
I think that this approach will work best. I can use distribution information and guess that the user is using the default DE on that distro. Users whom have either chosen a DE other than the default or opted for a distro without a default DE will in most cases be educated enough to make an informed choice on which version of Stoffi to download if I present him/her with 3-5 choices. These choices will be presented as big buttons for each DE.
Moving on to themeing I think it will be a short of hybrid here. I tend to think of icons as part of a theme and those will most likely be custom made to fit in with the environment. However, the GTK and Qt toolkits can handle gradients on buttons and details like that for me, so I won’t have to.
If you look at my current Win7 version it is actually themed very much. The selection gradient in the tree view and list view is custom made to mimic the look in Windows Explorer (default is just a plain dark blue color). I have also created a background for the right column on the control panel (preferences) as well as the title area above the list view. The playback buttons are made completely by hand in Adobe Illustrator and I tried to get them too look something like the buttons in IE7/8 and Windows Explorer. The search bar as well as the volume slider and seek slider are also designed completely from scratch.
So I will do some custom design if I have to, but I will avoid it if the toolkit can give me the look I want. For example, I have not touched the buttons in the Win7 interface or the context menus since they are already good.
There will be no way for the user to change this manually. I have code in my Win7 interface to detect if the user is running Aero, Basic or Classic though.
In short, my goal is to make Stoffi feel like it’s part of the system and not a third party app. I will do as little work as possible to get there.
My absolute favorite interface, ever: Music Match Media Player V 7-9 Pre Yahoo takeover. Best feature missing from modern players: playlist related actions. You could take the now playing list, easily save it as a play list, burn to cd in a few easy to see clicks. A play list could also be created with the “auto DJ” that would allow you to choose a time length for the playlist, and which genres/albums/artists to choose from, it would then randomly pick them to fill the time amount as best as possible. New features were added such that they were easily discover-able and instantly understandable without being a distraction and easily removed if not wanted. Can you imagine what it would have looked like if it had tried to blend in with windows 95/98? Horrible…
Favorite Now: Amarok (qt based), just missing a good way to deal with USB mass storage systems ( aka portable music players). Should be improved with next release.
Rhythmbox (GTK native) is also ok. I use it for the features Amarok doesn’t do well with like portable media players.
About the “auto DJ” thing, I actually made a similar feature recently. Although I let you choose number of tracks and not total length but I should really add that as well (or total size).
About the Win95/98: but you would only see that “horrible” interface when you run it on Windows 95 or Windows 98. The KDE interface might not even have the play/pause buttons at the same place if it didn’t make sense in KDE. That’s what I am aiming for. On Win7 I don’t have a status bar, but maybe I should on the KDE version?
I used to use Amarok when I was an avid KDE user (back in the 2.x and 3.x days) and it was my favorite music player of all time. It was so much more awesome than XMMS which I had previously used. I find it hard to feel that love again today since the UI of Amarok has changed so much since then. I can’t really like it anymore. And the same goes for both Rythmbox and Banshee. They might all be OK or even well integrated with their respective DE but their interfaces don’t give me that feeling of elegance that I would like it too.
So that’s why I look forward to trying out something myself and see what I can come up with.
You’re using C# which is a good thing. It is very well supported on Windows (obviously) and on OSX (through MonoMac). Extending this to Linux is simply a matter of finding up to date Qt bindings, and using GTK# (Since Linux is effectively split into two camps, UI technology wise.)
Again, since you’re using C#, it should be dead simple to use separation of concerns to achieve highly reusable code. Use Inversion of Control and other Agile principles to enable maintainable, portable code.
C# is to the best of my knowledge, really, the only language which even facilitates something close to cross platform nirvana. To me, your lowest hanging fruit is Mac support (MonoMac is excellent, btw), from there GTK# is your next best bet.
The trick is to follow the UI guidelines of the host platform, as strictly as you can. You’ve done your job if your users can’t even tell that the app is cross platform.
Don’t buy into the one platform to rule them all hype spouted by ideologues who’ve never written, let alone maintained a line of code in their life, from usability it’s a crap point of view.
Edited 2012-01-23 20:37 UTC
Yeah, the architecture is there, I have modularized it so I can swap out the interface with ease but now I am planning on doing all these other interfaces. Cocoa# and GTK# are both pretty stable and well documented. Qyoto or Qt# however, not so much. Outside that (for my Fluxbox version or Haiku version perhaps?) I still have the problem of finding good bindings for a good toolkit.
Yeah, thats why I mentioned the difficulty. Last time I checked, the Qt bindings were poorly maintained. I’m not sure if MonoMac = Cocoa#, last I checked MonoMac included very rich (beyond just UI Toolkit APIs) Mac integration.
I’m just not sure what good options there are for Qt. There’s always doing some native interop, but that gets nasty quickly..though it probably will be needed eventually for other WM integration.
Other problems I foresee are paradigm differences. Cocoa for example favors MVC, whereas WPF/SL/WinRT favor MV+VM and rich databinding, anything else is anyone’s guess.
I’ve had decent success using a loosely coupled Messenger implementation with MonoMac over trying to shoehorn INotifyPropertyChanged to fit in a Cocoa world.
Yeah, the Mac version of Mono (I’ve heard) should be very good. It’s great that there’s more integration than just the toolkit. Really something I will look into when doing the Mac GUI.
Someone mentioned that I could go for GTK# in LXDE and XFCE as well as Gnome. So that would cover a lot more, even if I might have to do two versions there due to the vast difference between Gnome 3 and the other GTK DEs. For Fluxbox and Enlightenment (and other) I could go for a heavily themed GTK# UI.
The paradigm issues will be interesting to wrestle with. I have tried my best to make my Core as generic as possible but there is a lot of use of INotifyPropertyChanged actually. I might have some fun times ahead…
How about making your app web-pased then it looks and behaves the same everywhere no matter which OS is used to access it and also you can support mobile platforms like Android and iOS and MeeGo, Tizen and what all they are.
So if you want native application everywhere, create a webapp.
I would say that the web is not native anywhere.
(But yeah, a web app is in the works as well. However, there’s limitations to web apps so native versions will also be created).
A web application is exactly the opposite of what having a native application means.
The web is “Run once, test everywhere”. Performance still isn’t there, look and feel still isn’t there, and Javascript is a goddamn abomination. HTML isn’t an application markup language. It will never be.
Yep web is not native from the OS point of view but it is native from the users point of view. So if the problem can be solved with simple webapp, then hat is enough for user. It looks the same everywhere and for the user, the app is native WEB APPLICATION. If it runs on browser then user expects certain behaviour. If it runs as standalone application though, expectations start to vary.
So is OsNews native (web-based news site)?
Tcl/Tk w/ Cygwin/X bundled is the way to go, no doubt.
I am curious about some “native” look and feel applications that also target Linux, I know a few like Skype, Spotify, RStudio that use Qt. I know a few that use GTK like Pidgin or Chrome but there seems to be more discussion in the abstract rather than examples.
I second that. I would love to hear some examples of cross platform application. Which can you tell are ported to Linux and which feel like they developed for Linux and Linux only?
davidpitkin,
“I know a few like Skype, Spotify, RStudio that use Qt. I know a few that use GTK like Pidgin or Chrome but there seems to be more discussion in the abstract rather than examples.”
Not blaming QT here, but skype’s UI design has deteriorated to just awful in it’s version 5 incarnations. The linux version stops at 4, which is very buggy with it’s own problems, but in many ways the older interface is superior. Skype 5 is so bad that I’ve had to VNC to my family’s computer because I couldn’t walk them through it over the phone (which in itself is super ironic).
AFAIK Win version of Skype never even used Qt (that’s only Linux version) – rather, what ~Delphi* uses by standard, I believe (perhaps it wraps fairly usual MS ~toolkits).
And yeah, the Skype UI deteriorated… hopefully it will be cleaned now, under MS – maybe there is something with which overall Metro push might be potentially useful.
BTW guiding (even so called “computer illiterate”) people over the phone, with the purpose of setting up VoIP software – I repeatedly found Gtalk to be by far the smoothest in this regard (and in more – for example, it tends to function much better than Skype on really bad connections, like way over-shared Wifi on one end, modem dial-up connection, deep in CIS, on the other; also: http://www.kyon.pl/img/17590,comparison,gtalk,Windows_Live_Messenge… )
Too bad its Win32 client is quite neglected for the past few years (so far it works well, but…), and doesn’t support Gmail videoconferencing (which also tends to be, from my experience, the best on bad connections, possibly thanks to http://en.wikipedia.org/wiki/Vidyo ). At least Pidgin is getting decent with supporting Gtalk/Gmail features (so I guess it will be just guiding “illiterates” through Gmail, in the future)
*this could be a bit interesting, given how they are now “Microsoft Skype”
Unity, even has adopted it for their 2d interface and ubuntu TV. By coding it in Qt you make it native in KDE, and look native in GTK environments since Qt has a gtk theme engine and a clearlooks theme.
You can check the following wiki for some more information
https://wiki.archlinux.org/index.php/Uniform_Look_for_QT_and_GTK_App…
Furthermore you will have the advantage of a single codebase that can work on all of the platforms, which brings home the Java montra code once run everywhere. Unlike java the programs won’t have a shitty theme but would look / act more or less native. Plus you gain access to a 2d canvas and a declarite API with Qtquick.
Well I’m actually planning to not use a single toolkit but instead have one for each environment. So there’s no reason for me to go for both a Qt and a GTK interface. There will perhaps be even more since I think a Unity interface will have to differ from an LXDE interface.
I am going for the feeling that Stoffi should feel like it’s part of the DE and not a third party application.
The only toolkit i know of that does support native feel, (or almost native) look and works on many plattforms is QT
Plattform list :Embedded Linux, Mac OS X, Microsoft Windows, Most available/X11 (linux, bsd, hp-ux, AIX, solaris and many more), Windows CE, Symbian, MeeGo, Haiku, Amiga OS, OS/2, eComstation, QNX, Wayland, iPhone, webOS, Kindle, Android, Blackberry, Windows CE, and more to come.
What would you say are the main drawbacks to using Qt on Gnome 3 instead of a GTK interface?
Obvious ones are extra dependencies and slower loading time (if there is no other Qt application running).
In addition to that, settings are handled differently – Gtk applications use gconf, Qt uses .ini files. So if you configure http proxy for gnome, Qt application will probably ignore it,
http://developer.apple.com/library/mac/#documentation/UserExperienc…
Not everything is in the guidelines. I have read them and will follow them as much as I can. But I want to know the smaller annoyances that users of these systems experience when it comes to apps not feeling native, or what their dream music app would be like if it was to feel like a part of the system and not third party.
today I stumble on this article:
http://www.panic.com/extras/audionstory/
it is about creating first mp3 player for Mac OS and about roots of iTunes… maybe you will find it interesting or inspiriting (but you will not find “how to do it” guide)
Surprised everyone hasn’t mentioned this. Songbird uses XUL.
https://developer.mozilla.org/en/Getting_started_with_XULRunner
Firefox use it for it GUI …
I looked at this for my dissertation, but I decided to use Java + SWT instead (which isn’t an option for you).
Edited 2012-01-24 10:54 UTC
Interesting. Maybe the XUL has more potential than what Mozilla uses in Firefox though, cause I’ve always had the feeling that while Firefox feels more like a Gnome app then a KDE app it’s really not anything; it’s Firefox.
Personally I wouldn’t bother supporting a platform unless I suspect to get at decent percentage of users.
But it seems more of an intellectual exercise (which is fine), but I certainly wouldn’t know where to look for a native look and feel for Linux because tbh there isn’t one.
Maybe not for “Linux” but there certainly is a native look and feel for KDE and for Gnome, and so on…
When you do something “just” for fun you get to play around with cool stuff like this.
Hi, I just tried Stoffi and really like it. Let me say that you guys are awesome at doing this!
Here’s little things I found that need some improvement (on the windows side of things):
1. I notice that after you enter the “Preferences” Menu that you have to click on the “Back to music” menu on the side panel. Interestingly, I tried to search for back button, like in explorer (I think it’s because you want to make it behave like windows, especially explorer, CMIIW). Then I realize that on the top panel is the music control. This feel really strange, as everywhere in explorer and other app (like Control Panel), the top panel is always for navigation.
2. I think you need to move the music control and status to the bottom panel, while leaving the top panel for navigation and search. There’s a detail of the song played in the bottom panel, but I think it’s duplication because we already have the detail on the song list. That way, it’s more consistent not only with Windows, but with other music players as well. Also see how explorer shows the detail of the drive selected when we highlight a drive on Computer. I think you need to show the detail of the song played for Stuffi to behave more like explorer.
3. The close button on the top left of the application window is always highlighted Red in almost all native Windows application.
4. The dividing line between the main panel and the left panel is too bold. See the following image:
http://img402.imageshack.us/img402/2835/stuffi.png
Hope this helps. I really want to help out hacking the application, but for now I think I can’t give you many help in that area.
Also, sorry for my english
Edited 2012-01-24 10:56 UTC
Found some other:
1. In Windows, I believe that the mouse cursor will only change to “pointer” when we select the link. The play/pause, ff, rwd, shuffle, and random button should not change the mouse cursor shape when hovered. See also Windows Media Player on this. Another interesting note is that the name for the “pointer” cursor is “Link Select” (see the “Mouse” item on Control Panel).
2. The links on the side bar, on the other hand, should change the mouse cursor to “pointer” when hovered.
Edited 2012-01-24 11:09 UTC
Thanks! It’s really fun when people enjoy the stuff I make.
I could add a back button at the top and try to make it blend in with the rest. It would make it easier to navigate, especially between Preferences and “normal”. I will keep it in mind!
Well the bottom pane is just like in Explorer. It’s details about the stuff you have currently selected. In the stable version that is out right now we only show a single file. In alpha we have added the ability to see a summary of all selected tracks. I plan on adding details for when selecting a playlist, youtube or anything else in the left hand navigation tree.
So the bottom pane is actually supposed to be exactly the same as it is in Explorer. Which will make it hard to put the playback buttons and current playing song info there.
I guess I put playback at top because I had been a heavy user of Amarok before I went to Win7 and found myself missing a great music player.
It’s not? I just fired Stoffi up and the close button is red there as well. Unless the window loses focus, then it becomes transparent (just like minimize and maximize/restore), but that is consistent with all the other apps as well. In fact, I’m not touching those buttons, they are handled by .NET (and in extension by DWM I believe, someone could correct me on this).
Good point. I have actually made it a bit broader as a temporary solution. Since if I make it thinner it will be hard to hit. It seems that I want a broad hit area and a thin line. But I have not yet figured out how to have the hit area differ from the painted line. But definitely something I should fix.
I haven’t thought of that. I will fix it in the next release.
I’ll take any help I can get. There’s always a need for anything from programming and design to translation and promotion. And my policy is that people work as much or as little they want, with what they want and for as long as they want, be it a day, a week or a year.
If you want to contribute you can send me a message.
I can see what you mean. But still a little inconsistency though, for example, when we select one song that’s not playing and move to the “Now Playing” link, the bottom pane still details the selected music. Shouldn’t it details the currently playing music?
Well, my bad. I forgot that I just turned off focus follows mouse, so I didn’t notice that the window is not active when I see it.
For now I don’t have the time, but I’ll try to find some time to contribute, and then I’ll contact you for sure. I’m looking forward for the time
Off the top of my head, I can think of at least two well known projects that have done something along these lines – but perhaps not as ambitious to try to cover all the major platforms as yours – and those are Avidemux and Transmission. I don’t know what the Windows version of Avidemux uses (Qt?) but in Linux, there is a core package and then a plug-ins package and finally two different UIs packages: one for GTK and another for Qt. I don’t know if Transmission has a Windows version but it also has two different front-ends in Linux (This is on Debian Sid, it may be packaged differently on other distros):
avidemux – Free video editor (GTK version).
avidemux-cli – Free video editor (command line version).
avidemux-common – Free video editor (Internationalization files).
avidemux-plugins – Free video editor (plugins).
avidemux-qt – Free video editor (QT version).
…
transmission – lightweight BitTorrent client
transmission-cli – lightweight BitTorrent client (command line programs)
transmission-common – lightweight BitTorrent client (common files)
transmission-daemon – lightweight BitTorrent client (daemon)
transmission-dbg – lightweight BitTorrent client (debug symbols)
transmission-gtk – lightweight BitTorrent client (GTK interface)
transmission-qt – lightweight BitTorrent client (Qt interface)
The separation of functionality from the UI even allows some niceties such as the web front-end for the Transmission daemon that actually used to be a separate project (Clutch) but that has been absorbed into the main app a few iterations ago and it is really well done (In fact, it looks like an OS X app).
You might want to take a look and see their respective coding styles, roadmaps, check the lessons learned, what pitfalls to avoid, etc to help you to define yours.
If I had to be bothered to create a multi-platform application and Java SWT/Swing is not on the cards due to its inherent ugliness, I’d definitely have gone with Qt, though. It just sounds more reasonable and less troublesome for the long haul to maintain just one codebase and compile for different platforms or desktop environments as needed if the price to pay is just a few widgets that *might* look slightly off in a few corner cases.
Edited 2012-01-24 17:21 UTC
Thanks!
This will let me sit down and really analyze every difference between their versions. Maybe I can find some goodies in there.
Have you any experience with them? Do you know if there’s any pitfalls or shortcomings they have not anticipated? Any mistakes you think I can learn from?
Other than as an user, I do not know much about neither application. What I can tell is that both front-ends seem identical functionality-wise but take that with a grain of salt as I mostly use the Qt versions ever since they became available.
Avidemux is really a multi-platform app and does not even pretend to integrate too much with the underlying operating system/desktop environment in a sense that it uses the same icons and UI conventions in all platforms and only the basic widgets (buttons, scroll bars, etc.) seem/feel “integrated”. Not saying that I don’t enjoy using it because of that by the way: I really love that app and couldn’t care less about the way it looks. In fact, working consistently across the different platforms it supports is a plus in my book, not a minus.
Transmission on the other hand does a great job to properly integrate into KDE, using the native notifications API, Oxygen icons and what not. They’ve really gone the length to properly make it feel properly integrated. It truly feels like a KDE application. It will probably be more useful than the former for you as a research subject (as far as Linux is concerned).
VLC changed completely from GTK to Qt not too long ago but it did not bother GNOME users concerned with consistence on their desktops too much due to Qt’s awesome themeability. You can check it up yourself by going to VLC and then clicking on Tools > Preferences and then on Interface change the option under “Force window style”. It does not change icons or open/save dialogs to GTK+ style but in my limited understanding of its capabilities, I believe that Qt can in fact do those things if one wants to (not that I would EVER switch to GTK open/save style dialogs unless forced to!)
Edited 2012-01-26 15:49 UTC
Hello,
This is just an informal observation, but I tend to find that the ported apps on OS X that don’t feel right are the ones with too much clutter – multiple panels along the top, down the bottom, and particularly a reliance on toolbar buttons. (That’s aside from getting the fonts and button sizes, etc, “native”.)
One example among the apps I have here is Evernote (could be an old version – 1.10.1 – don’t use it that much), which uses the right widgets and looks and all but feels cramped for a Mac app, with a login-type of bar under the toolbar, three vertical panes, three panes in the leftmost one and three toolbars in the rightmost column where you type text.
This sort of thing can feel awkward, or foreign I guess, even where it isn’t extreme.
From the screenshot you’ve included in the article, your interface looks simple and lovely. Even so, I’m not sure how the “Add, Show, Tools…” strip of menus would translate to OS X. The bottom panel of track information may or may not work as well.
Among other tiny points (but I suppose the minutiae are what you’re canvassing) is the volume slider, which is obviously a volume slider and everyone would recognise it as such, but without any icons or other friendly signposting, it appears to me to have a whiff of being a bit of a technical apparatus, in terms of aesthetics anyway. The icons of sound files next to the tracks in the main music library list would be out of place on Mac desktops too, I would think.
I suppose, though, with these look and particularly feel questions, it’s hard to know unless you take a whirl on it to get a feel.
You’re brave to seek help so openly. Good luck.
Thanks a lot! Your post is a gold treasure full of good points. Awesome.
I think the Add, Show, etc would go into the global menubar perhaps?
It just works.
Forget about design!
Who really cares about design for more than a few hours anyways, after that functionality is what matters..
Interface design, UX design, flow design, system design. Not everything is about the graphics.
I agree with the author. A consistent, native look is important to me, too. I shake my head when I see programs like firewalls or antivirus software skinning their interface, while their priority should be the protection of my computer.
On the screenshot, I was surprised to find foobar2k included. Its native look and feel was among the reasons I switched to it. Yeah, with its default settings it looks ugly, but in no way it “sports its own interface principles, its own look and feel, …”.
Or, to say it in other words: Stoffi is not going to win me over because of its interface, since foobar2k is good enough already. The features matter. And as long Stoffi isn’t a “better fb2k than fb2k”, I don’t see myself using it. So until I gave it a try, I’ll just say: It is, nevertheless, a nice project with a commendable basic concept, so I’m sure it’ll appeal to others.
Edited 2012-01-25 01:47 UTC
I included fb2k mostly because it looks out of place by default on my Windows 7 machine. It did look a bit better on XP when I used it there before I went over to live in the Linux camp for over 7 years (where Amarok was my mostly used application).
I think that functionality is a very important aspect as well to make an application feel really integrated with the host operating system. For example, Stoffi will automatically scan the Windows 7 Libraries of type “Music” to find music files. It also uses Jumplists and Taskbar buttons. These are part of the UX design IMO and help provide that integrated feeling.
fb2k is not nearly as bad as Winamp or iTunes when it comes to disrespecting the UI conventions.
I haven’t used fb2k for several years but I remember that I liked the way it was so “tiny” but had so much. My project looks way bigger but I am still inspired by its simplicity and its very small size (both as a download package and when installed).