Username or EmailPassword
Use The Qt4 library -- it is the closest you can get to a native look & feel, while still retaining cross-platform code portability.
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.
Qt is good enough to be portable.
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.
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
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?
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.
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
For a music / media player:
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 Étoilé GNUStep looks nice...
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:
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:
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.
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:
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.
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.
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:
You can see how the gradients, buttons, dialog boxes, tabs, etc. all look consistent with other Mac applications.
On KDE and GNOME/Unity:
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.
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.
"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
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.
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?
"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
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,
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:
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.
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:
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
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
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?
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).