Linked by ephracis on Mon 23rd Jan 2012 13:18 UTC
General Development 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 OSNews to help me do this.
Order by: Score:
Use Qt4 library
by Alexey Technologov on Mon 23rd Jan 2012 13:41 UTC
Alexey Technologov
Member since:
2007-03-16

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.

Reply Score: 6

RE: Use Qt4 library
by FreakyT on Mon 23rd Jan 2012 13:49 UTC in reply to "Use Qt4 library"
FreakyT Member since:
2005-07-17

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.

Reply Score: 6

RE[2]: Use Qt4 library
by Laurence on Mon 23rd Jan 2012 14:17 UTC in reply to "RE: Use Qt4 library"
Laurence Member since:
2007-03-26

Each user should get the impression that the application was designed for his operating system only.


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

Reply Score: 7

RE[3]: Use Qt4 library
by gan17 on Mon 23rd Jan 2012 14:26 UTC in reply to "RE[2]: Use Qt4 library"
gan17 Member since:
2008-06-03

In that case your Linux client should be CLI only :p

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

Reply Score: 3

RE[4]: Use Qt4 library
by ephracis on Mon 23rd Jan 2012 22:15 UTC in reply to "RE[3]: Use Qt4 library"
ephracis Member since:
2007-09-23

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.

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! ;)

Reply Score: 2

RE[2]: Use Qt4 library
by shmerl on Mon 23rd Jan 2012 17:06 UTC in reply to "RE: Use Qt4 library"
shmerl Member since:
2010-06-08

Qt is good enough to be portable.

Reply Score: 2

RE[3]: Use Qt4 library
by ebasconp on Tue 24th Jan 2012 00:58 UTC in reply to "RE[2]: Use Qt4 library"
ebasconp Member since:
2006-05-09

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).

Reply Score: 4

RE[2]: Use Qt4 library
by ephracis on Mon 23rd Jan 2012 22:12 UTC in reply to "RE: Use Qt4 library"
ephracis Member since:
2007-09-23

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.

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).

Reply Score: 2

RE[3]: Use Qt4 library
by bosco_bearbank on Tue 24th Jan 2012 01:39 UTC in reply to "RE[2]: Use Qt4 library"
bosco_bearbank Member since:
2005-10-12

[q] 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

Reply Score: 2

RE[4]: Use Qt4 library
by ephracis on Tue 24th Jan 2012 07:24 UTC in reply to "RE[3]: Use Qt4 library"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE[5]: Use Qt4 library
by gfolkert on Tue 24th Jan 2012 14:09 UTC in reply to "RE[4]: Use Qt4 library"
gfolkert Member since:
2008-12-15

{snip}... 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.

Reply Score: 1

RE[6]: Use Qt4 library
by ephracis on Tue 24th Jan 2012 14:12 UTC in reply to "RE[5]: Use Qt4 library"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 3

RE[7]: Use Qt4 library
by DaveDavtropen on Tue 24th Jan 2012 22:42 UTC in reply to "RE[6]: Use Qt4 library"
DaveDavtropen Member since:
2009-03-20

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

Reply Score: 1

RE[3]: Use Qt4 library
by TemporalBeing on Tue 24th Jan 2012 17:01 UTC in reply to "RE[2]: Use Qt4 library"
TemporalBeing Member since:
2007-08-22

"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.

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).
"

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.)

Reply Score: 3

RE[4]: Use Qt4 library
by ephracis on Tue 24th Jan 2012 17:07 UTC in reply to "RE[3]: Use Qt4 library"
ephracis Member since:
2007-09-23

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?

Reply Score: 2

RE[5]: Use Qt4 library
by TemporalBeing on Tue 24th Jan 2012 18:26 UTC in reply to "RE[4]: Use Qt4 library"
TemporalBeing Member since:
2007-08-22

Well to start with the C# bindings for Qt are very badly supported.


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.

Secondly, and more importantly, if we discard the "look", let's focus on the "feel".


Your mixing apples and oranges by trying that.

For example we have different ordering of OK/Cancel buttons.


You're way off the target on this one. See below.

So needless to say, that's a misnomer in this whole discussion.

There's also the configurability of the DEs themselves which sets a different environment for the user.


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.

Are there any other differences between Qt apps and GTK apps when it comes to feel?


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.

Reply Score: 2

RE[6]: Use Qt4 library
by ephracis on Wed 25th Jan 2012 08:04 UTC in reply to "RE[5]: Use Qt4 library"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE[7]: Use Qt4 library
by TemporalBeing on Wed 25th Jan 2012 15:26 UTC in reply to "RE[6]: Use Qt4 library"
TemporalBeing Member since:
2007-08-22

I think you missed the point of the whole project


You are talking apples and oranges


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.


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 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.


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.


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.


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.

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.


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.

I want to put the focus on the content, and I want to do that in an integrated and seamless way.


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.

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.


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.)

Reply Score: 2

RE[2]: Use Qt4 library
by TemporalBeing on Tue 24th Jan 2012 17:06 UTC in reply to "RE: Use Qt4 library"
TemporalBeing Member since:
2007-08-22

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.


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.

Reply Score: 2

RE[3]: Use Qt4 library
by ephracis on Wed 25th Jan 2012 22:05 UTC in reply to "RE[2]: Use Qt4 library"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE[4]: Use Qt4 library
by TemporalBeing on Wed 25th Jan 2012 23:03 UTC in reply to "RE[3]: Use Qt4 library"
TemporalBeing Member since:
2007-08-22

"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.
"

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.

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 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.

Reply Score: 2

UI Trends
by FreakyT on Mon 23rd Jan 2012 13:53 UTC
FreakyT
Member since:
2005-07-17

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.

Reply Score: 3

gnome human interface guidelines
by r0b0 on Mon 23rd Jan 2012 14:05 UTC
r0b0
Member since:
2006-09-21

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

Reply Score: 3

RE: gnome human interface guidelines
by nasam on Mon 23rd Jan 2012 14:27 UTC in reply to "gnome human interface guidelines"
nasam Member since:
2012-01-23

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.

Reply Score: 2

ephracis Member since:
2007-09-23

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.

Reply Score: 2

GNUStep to the rescue!
by tidux on Mon 23rd Jan 2012 14:23 UTC
tidux
Member since:
2011-08-13

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.

Reply Score: 1

RE: GNUStep to the rescue!
by No it isnt on Mon 23rd Jan 2012 15:47 UTC in reply to "GNUStep to the rescue!"
No it isnt Member since:
2005-11-14

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?

Reply Score: 2

RE[2]: GNUStep to the rescue!
by tidux on Mon 23rd Jan 2012 21:25 UTC in reply to "RE: GNUStep to the rescue!"
tidux Member since:
2011-08-13

I do. I kinda oscillate between Window Maker, StumpWM, and GNOME, depending on the system specs and my mood.

Reply Score: 1

RE[3]: GNUStep to the rescue!
by ephracis on Tue 24th Jan 2012 07:27 UTC in reply to "RE[2]: GNUStep to the rescue!"
ephracis Member since:
2007-09-23

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?

Reply Score: 2

RE[4]: GNUStep to the rescue!
by tidux on Tue 24th Jan 2012 15:09 UTC in reply to "RE[3]: GNUStep to the rescue!"
tidux Member since:
2011-08-13

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.

Reply Score: 2

RE[5]: GNUStep to the rescue!
by ephracis on Wed 25th Jan 2012 22:11 UTC in reply to "RE[4]: GNUStep to the rescue!"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE: GNUStep to the rescue!
by wazoox on Mon 23rd Jan 2012 16:34 UTC in reply to "GNUStep to the rescue!"
wazoox Member since:
2005-07-14

With √Čtoil√© 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.

Reply Score: 2

RE: GNUStep to the rescue!
by robertson on Tue 24th Jan 2012 05:56 UTC in reply to "GNUStep to the rescue!"
robertson Member since:
2010-04-30

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

Reply Score: 2

Client-server architecture
by maarten on Mon 23rd Jan 2012 14:26 UTC
maarten
Member since:
2006-11-10

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".

Reply Score: 5

RE: Client-server architecture
by ephracis on Mon 23rd Jan 2012 16:22 UTC in reply to "Client-server architecture"
ephracis Member since:
2007-09-23

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!).

Reply Score: 3

RE[2]: Client-server architecture
by ashes_786 on Mon 23rd Jan 2012 19:08 UTC in reply to "RE: Client-server architecture"
ashes_786 Member since:
2011-10-22

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 :-)

Reply Score: 1

Good Luck
by bryhhh on Mon 23rd Jan 2012 14:58 UTC
bryhhh
Member since:
2005-07-22

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

Reply Score: 2

RE: Good Luck
by ephracis on Mon 23rd Jan 2012 22:20 UTC in reply to "Good Luck"
ephracis Member since:
2007-09-23

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).

Reply Score: 2

Difficult
by r_a_trip on Mon 23rd Jan 2012 15:36 UTC
r_a_trip
Member since:
2005-07-06

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.

Reply Score: 4

RE: Difficult
by ephracis on Mon 23rd Jan 2012 22:24 UTC in reply to "Difficult"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

native to Linux?
by areks on Mon 23rd Jan 2012 15:41 UTC
areks
Member since:
2008-11-10

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.

Reply Score: 5

RE: native to Linux?
by ephracis on Mon 23rd Jan 2012 22:26 UTC in reply to "native to Linux?"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

Linux is only a kernel
by Z_God on Mon 23rd Jan 2012 15:43 UTC
Z_God
Member since:
2006-06-11

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!

Reply Score: 4

RE: Linux is only a kernel
by ephracis on Mon 23rd Jan 2012 22:28 UTC in reply to "Linux is only a kernel"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE[2]: Linux is only a kernel
by Z_God on Tue 24th Jan 2012 09:53 UTC in reply to "RE: Linux is only a kernel"
Z_God Member since:
2006-06-11

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.

Reply Score: 1

RE[3]: Linux is only a kernel
by ephracis on Tue 24th Jan 2012 10:09 UTC in reply to "RE[2]: Linux is only a kernel"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

RE[4]: Linux is only a kernel
by Z_God on Wed 25th Jan 2012 09:49 UTC in reply to "RE[3]: Linux is only a kernel"
Z_God Member since:
2006-06-11

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).

Reply Score: 1

In Linux I think you will have to...
by Tuishimi on Mon 23rd Jan 2012 15:54 UTC
Tuishimi
Member since:
2005-07-06

...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.

Reply Score: 2

Tuishimi Member since:
2005-07-06

Nice! I downloaded and donated.

Reply Score: 2

ephracis Member since:
2007-09-23

Awesome! Thank you so much. And congratulations: you are the first donor! I wish more people were like you *hint* ;)

Reply Score: 2

Tuishimi Member since:
2005-07-06

I hope more do, too.

Reply Score: 2

Comment by Luminair
by Luminair on Mon 23rd Jan 2012 15:57 UTC
Luminair
Member since:
2007-03-30

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.

Reply Score: 2

RE: Comment by Luminair
by ephracis on Mon 23rd Jan 2012 22:30 UTC in reply to "Comment by Luminair"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

wxWidgets
by joehms22 on Mon 23rd Jan 2012 16:02 UTC
joehms22
Member since:
2011-08-01

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.

Reply Score: 1

RE: wxWidgets
by ephracis on Mon 23rd Jan 2012 22:31 UTC in reply to "wxWidgets"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

Mac OS X Human Interface Guidelines
by Heard on Mon 23rd Jan 2012 16:23 UTC
Heard
Member since:
2009-12-24

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.

Reply Score: 1

Modularize
by moondevil on Mon 23rd Jan 2012 16:25 UTC
moondevil
Member since:
2005-07-08

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.

Reply Score: 2

RE: Modularize
by BeamishBoy on Mon 23rd Jan 2012 18:35 UTC in reply to "Modularize"
BeamishBoy Member since:
2010-10-27

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.


*cough* Gang of Four *cough*

Reply Score: 1

RE: Modularize
by ephracis on Mon 23rd Jan 2012 22:36 UTC in reply to "Modularize"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

backblaze article
by FunkyELF on Mon 23rd Jan 2012 16:53 UTC
FunkyELF
Member since:
2006-07-26

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...

Reply Score: 2

RE: backblaze article
by ephracis on Mon 23rd Jan 2012 22:38 UTC in reply to "backblaze article"
ephracis Member since:
2007-09-23

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? ;)

Reply Score: 2

KDE4
by dnebdal on Mon 23rd Jan 2012 16:59 UTC
dnebdal
Member since:
2008-08-27

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.

Reply Score: 2

RE: KDE4
by ephracis on Mon 23rd Jan 2012 22:40 UTC in reply to "KDE4"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

Linux: GNOME and KDE flavors needed
by ddc_ on Mon 23rd Jan 2012 17:56 UTC
ddc_
Member since:
2006-12-05

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.

Reply Score: 2

ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

ddc_ Member since:
2006-12-05

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.

Reply Score: 1

ephracis Member since:
2007-09-23

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.

Reply Score: 2

Qt4
by chenxiaolong on Mon 23rd Jan 2012 18:10 UTC
chenxiaolong
Member since:
2011-12-05

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 ;)

Reply Score: 4

RE: Qt4
by stew on Mon 23rd Jan 2012 22:17 UTC in reply to "Qt4"
stew Member since:
2005-07-06

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.

Reply Score: 2

RE[2]: Qt4
by ephracis on Mon 23rd Jan 2012 22:46 UTC in reply to "RE: Qt4"
ephracis Member since:
2007-09-23

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?

Reply Score: 2

v Native Opensource?
by ParadoxUncreated on Mon 23rd Jan 2012 18:11 UTC
RE: Native Opensource?
by ephracis on Mon 23rd Jan 2012 22:51 UTC in reply to "Native Opensource?"
ephracis Member since:
2007-09-23

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...

Reply Score: 2

One UI to rule them all?
by Bill Shooter of Bul on Mon 23rd Jan 2012 20:00 UTC
Bill Shooter of Bul
Member since:
2006-07-14

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.

Reply Score: 2

RE: One UI to rule them all?
by ephracis on Mon 23rd Jan 2012 22:53 UTC in reply to "One UI to rule them all? "
ephracis Member since:
2007-09-23

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.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 2

ephracis Member since:
2007-09-23

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? ;)

Reply Score: 2

RE[4]: One UI to rule them all?
by Alfman on Tue 24th Jan 2012 00:01 UTC in reply to "RE[3]: One UI to rule them all? "
Alfman Member since:
2011-01-28

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

Reply Score: 3

ephracis Member since:
2007-09-23

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.

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).

Reply Score: 2

RE[6]: One UI to rule them all?
by Alfman on Tue 24th Jan 2012 12:57 UTC in reply to "RE[5]: One UI to rule them all? "
Alfman Member since:
2011-01-28

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.

Reply Score: 3

ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 2

ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

Suggestions
by Nelson on Mon 23rd Jan 2012 20:36 UTC
Nelson
Member since:
2005-11-29

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

Reply Score: 2

RE: Suggestions
by ephracis on Mon 23rd Jan 2012 22:55 UTC in reply to "Suggestions"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE[2]: Suggestions
by Nelson on Tue 24th Jan 2012 00:10 UTC in reply to "RE: Suggestions"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[3]: Suggestions
by ephracis on Tue 24th Jan 2012 07:47 UTC in reply to "RE[2]: Suggestions"
ephracis Member since:
2007-09-23

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... ;)

Reply Score: 2

Web is native everywhere
by wigry on Mon 23rd Jan 2012 20:45 UTC
wigry
Member since:
2008-10-09

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.

Reply Score: 1

RE: Web is native everywhere
by ephracis on Mon 23rd Jan 2012 22:57 UTC in reply to "Web is native everywhere"
ephracis Member since:
2007-09-23

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).

Reply Score: 2

RE: Web is native everywhere
by moondevil on Mon 23rd Jan 2012 23:09 UTC in reply to "Web is native everywhere"
moondevil Member since:
2005-07-08

A web application is exactly the opposite of what having a native application means.

Reply Score: 5

RE: Web is native everywhere
by Nelson on Tue 24th Jan 2012 00:11 UTC in reply to "Web is native everywhere"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE: Web is native everywhere
by wigry on Wed 25th Jan 2012 16:58 UTC in reply to "Web is native everywhere"
wigry Member since:
2008-10-09

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)?

Reply Score: 1

Jenius
by earksiinni on Mon 23rd Jan 2012 23:46 UTC
earksiinni
Member since:
2009-03-27

Tcl/Tk w/ Cygwin/X bundled is the way to go, no doubt.

Reply Score: 2

davidpitkin
Member since:
2010-01-06

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.

Reply Score: 1

ephracis Member since:
2007-09-23

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?

Reply Score: 2

Alfman Member since:
2011-01-28

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).

Reply Score: 2

zima Member since:
2005-07-06

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"

Reply Score: 2

Save time use Qt4
by redsteakraw on Tue 24th Jan 2012 04:54 UTC
redsteakraw
Member since:
2009-09-22

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.

Reply Score: 2

RE: Save time use Qt4
by ephracis on Tue 24th Jan 2012 07:53 UTC in reply to "Save time use Qt4"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

Toolkit
by judgen on Tue 24th Jan 2012 05:15 UTC
judgen
Member since:
2006-07-12

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.

Reply Score: 2

RE: Toolkit
by ephracis on Tue 24th Jan 2012 07:54 UTC in reply to "Toolkit"
ephracis Member since:
2007-09-23

What would you say are the main drawbacks to using Qt on Gnome 3 instead of a GTK interface?

Reply Score: 2

RE[2]: Toolkit
by qbast on Wed 25th Jan 2012 09:50 UTC in reply to "RE: Toolkit"
qbast Member since:
2010-02-08

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,

Reply Score: 1

link
by kovacm on Tue 24th Jan 2012 09:04 UTC
kovacm
Member since:
2010-12-16
RE: link
by ephracis on Tue 24th Jan 2012 13:26 UTC in reply to "link"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

RE[2]: link
by kovacm on Tue 24th Jan 2012 23:55 UTC in reply to "RE: link"
kovacm Member since:
2010-12-16

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)

Reply Score: 1

XUL
by lucas_maximus on Tue 24th Jan 2012 10:53 UTC
lucas_maximus
Member since:
2009-08-18

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

Reply Score: 2

RE: XUL
by ephracis on Tue 24th Jan 2012 13:28 UTC in reply to "XUL"
ephracis Member since:
2007-09-23

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.

Reply Score: 2

RE[2]: XUL
by lucas_maximus on Tue 24th Jan 2012 15:07 UTC in reply to "RE: XUL"
lucas_maximus Member since:
2009-08-18

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.

Reply Score: 2

RE[3]: XUL
by ephracis on Tue 24th Jan 2012 15:27 UTC in reply to "RE[2]: XUL"
ephracis Member since:
2007-09-23

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. ;)

Reply Score: 2

bertzzie
Member since:
2011-01-26

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

Reply Score: 1

bertzzie Member since:
2011-01-26

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

Reply Score: 1

ephracis Member since:
2007-09-23

Hi, I just tried Stoffi and really like it. Let me say that you guys are awesome at doing this!

Thanks! It's really fun when people enjoy the stuff I make. ;)

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.

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!

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.

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. ;)

3. The close button on the top left of the application window is always highlighted Red in almost all native Windows application.

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).

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

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. ;)

5. 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).

I haven't thought of that. I will fix it in the next release. ;)

6. The links on the side bar, on the other hand, should change the mouse cursor to "pointer" when hovered.


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.

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. ;)

Reply Score: 2

bertzzie Member since:
2011-01-26


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. ;)


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?


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).


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.


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. ;)


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 ;)

Reply Score: 1

DeadFishMan
Member since:
2006-01-09

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

Reply Score: 2

ephracis Member since:
2007-09-23

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?

Reply Score: 2

DeadFishMan Member since:
2006-01-09

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

Reply Score: 2

Clutter on Mac
by mdsama on Tue 24th Jan 2012 18:08 UTC
mdsama
Member since:
2005-07-08

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.

Reply Score: 1

RE: Clutter on Mac
by ephracis on Wed 25th Jan 2012 21:28 UTC in reply to "Clutter on Mac"
ephracis Member since:
2007-09-23

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?

Reply Score: 2

I suggest Tk...
by ViktorRabe on Tue 24th Jan 2012 19:50 UTC
ViktorRabe
Member since:
2011-12-30

It just works.

Reply Score: 1

Design. sigh...
by andih on Tue 24th Jan 2012 21:46 UTC
andih
Member since:
2010-03-27

Forget about design!
Who really cares about design for more than a few hours anyways, after that functionality is what matters..

Reply Score: 2

RE: Design. sigh...
by ephracis on Wed 25th Jan 2012 21:54 UTC in reply to "Design. sigh..."
ephracis Member since:
2007-09-23

Interface design, UX design, flow design, system design. Not everything is about the graphics.

Reply Score: 2

Agreed on native look, but...
by mightshade on Wed 25th Jan 2012 01:33 UTC
mightshade
Member since:
2008-11-20

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

Reply Score: 2

RE: Agreed on native look, but...
by ephracis on Wed 25th Jan 2012 22:00 UTC in reply to "Agreed on native look, but..."
ephracis Member since:
2007-09-23

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). ;)

Reply Score: 2