musikBox is ALMOST working -- I just can't get my string class to work properly with unicode strings. If you know any experienced Linux developers interested in helping, please let me know

Hey, cool. Heres what I need help with:

  1) standard ./configure, make, make install installation.  i use cmake because its easy, but its also extremely non standard.

  2) unicode strings: i use a cross platform string class called CStdString that wraps std::string and std::wstring. There is a CStdString::Format() function call that is similar to wsprintf(). If I do this:

  CStdString mystr;
  mystr.Format( L"%s", L"HELLO!" );
  wprintf( mystr.c_str() );
  wprintf( "n" );

I expect to see this:

  avatar@ricochet>./format_test
  HELLO!

But I actually see this:

  avatar@ricochet>./format_test
  H   

All the strings I use Format() with get truncated to one character. I don't yet have the *nix debugging skills to trace it out. If someone could fix this bug, musikBox would work again. It would alsosupport APE and MPC files in Linux (take that, windows!).

Developers can grab the latest musikCore source code:

http://prdownloads.sourceforge.net/musi … p?download

musikBox is in the project's CVS.

Please let me know if you find any interested parties -- it will run really smoothly in linux if we can take care of these two things.

Nice work there by me, signing up and then forgetting to log in.

[edit] Sourceforges CVS seems to be down at the moment, I'll try again a bit later

Hello,

I am a very experienced linux developer. I am also very familiar with the GNU autotools. I'm going to try poking around with the source in the next few days as I happen to have some free time. Is there still interest in the GTK port? have the bugs been fixed? Just curious if this is even an outstanding issue.

-Chandler

I got musikBox to work under Fedora Core 4, recently.

Next thing I'll possibly try is Gentoo.

Well, I just checked out the CVS source... first step is to get musikCore building cleanly w/ autotools in linux. Then i'll throw together an ebuild for Gentoo for it, and i can make rpm's as well... Could also try some .deb packages for the ubuntu/debian crowd... Next phase will be getting musikBox set up w/ the autotools (should be very simple after musikCore) and then I'll see about the bug mentioned in this and another post.... Let me know of further interest, and other features, as I am a hard core linux user, and also desperate for a good music player that isn't tied to KDE/Qt nastiness...

cheers,
-Chandler

*grumble grumble*

so the libraries used... are wretchedly configured for linux...

rephrase, one of the libraries used is wretchedly configured for linux, namely OpenThreads... loads of fun there... ahh well, patching it up as best i can...

taglib i think i can work with, it at least has 'taglib-config' to help out.. xine is easy, and once i tackle openthreads, we'll see about getting sqlite going.. more updates to come...

-cc

For those interested, i have a working CVS build of musikCore. I have successfully added a full autotools setup using libtool, autoconf, and automake to build. It includes a new package config file so that it can be easily used as a library in other autotools builds, namely musikBox. The autotools build of musikBox should be much simpler, as it will use most of the same work done for musikCore. I have tarballs, if you are interested, drop me an email. I'll try and put them up on a server at some point.... Any comments from the developers? I'd like to work on this with thier assistance.

-Chandler

Add my vote for this! I'm still at the stage of _trying_ to move to linux so once I get there it'd be wonderful to have musikBox! In terms of features... make it like musikCube!

I actually like the design of musikCube/Core/Box. Windows applications should have the GUI coded in a natural way, that works with other windows GUIs. linux GUIs should be coded directly for a linux GUI. wxWidgets, imo, while often looking good in windows, look terrible in linux, are insane bloated, and nearly impossible to use. wxMusik is the ugliest linux application I have ever tried to use. =/ I think I will be much happier with a natively GTK UI that uses the same backend library. That is imo the best design for cross-platform applications.

-Chandler

Otto wrote:

Yeah, the way to go is to put the functionality in easily portable, non-interface specific, pieces, and then code interfaces natively. With the new design, hopefully this will just mean that we will only need people to port/write interface plugins between OS's. The non-interface plugins should work with just recompiling (in theory).

One worry about this: if the interface becomes simply a plugin, then the plugin loading/unloading will have to be cross-platform. This could be more difficult than you might at first imagine because share object loading, and referencing is WinAPI specific in windows, and POSIX specific in Linux (may not be POSIX standard, but i thought it was..., its dlopen etc). This could prove to be problematic to code into a single executable. I would lean more towards the current layout:

* Portable library implementing core features.
* Portable plugin libraries.
---
* Non Portable OS specific GUI application that both loads the core library, and the plugins, and provides the glue between them in an OS specific manner.

However, if either someone has found a clean way to do portable dynamic library loading (IE, not with tons of #ifdef, #else, #endif blocks...) rock on, I just haven't seen a clean implementation of it.

Something else that might be of interest and is portable: using scripting languages for plugins with SWIG generating glue code. Could make portable plugin development, and plugin development in general much easier... just an idea, as I've been looking at the plugin system as it stands, and its a bit Visual Studio centric... =/ we'll see...

-Chandler

Otto wrote:

Yeah, exactly. That'd still be the same. Except that the GUI application will also load all its main interface bits from plugins as well.
...
Of course, in theory, you don't have to go that way with any interface. If you wanted to write a straightforward monolithic interface and just use the portable libraries, you could. Nothing stops you from doing that. The interface plugins are specific to your interface, I suppose. It'd be nice to have compatible interface plugins cross platform, but it might be infeasible.

I rather like the idea of the interface being broken down into components that can be loaded/unloaded as desired. I do not know how feasable this is with gtkmm, the GUI library in linux that musicBox uses (and the best one imho. ;]). I don't know how to do it off the top of my head, but there might be some way. I also don't know how feasable it is to have plugins add/remove bits from a unified interface in Windows. My understand had been (and this is dated, so please correct me if wrong) that a window generally had to create all its GUI elements at once. While a plugin could create a new window easily (ala miniCube or whatever the plugin is w/ the little UI for controling) but having elements within the main window change based on plugins may be difficult in windows, and I'm certain it would be difficult in linux. The hardest part i forsee in this whole idea is the layout issue. How do you layout the main window if each element is provided by a plugin that may or may not be there? Especially if you have to assume that there will be new interface elements written that you don't know about yet? how do they fit into the interface?

A possible compromise would be to have an area of the interface for plugins, and let what plugins are there fill it up, and be organized as the user sees fit. That would still allow some elements of the UI to be extended w/ plugins, and allow plugins to have GUI components, but the layout of the main application wouldn't have to understand all the UI plugins ahead of time.

Perhaps this whole discussion is beyond the scope of this thread though? Very interesting however. =] I am looking forward to having this thing running in linux.... sooo close... (installing libraries i didn't have and glade right now, then i start debugging musikBox)

-Chandler