New Linux Project (windows maybe)

**bigb** · 04-23-2004, 08:54 PM

CVS updated.

**hijinks21** · 04-23-2004, 11:50 PM

i had to change this function in the mplayer.cpp

Code:

QString GetDefaultCfg() {
   QString CfgFile="<!DOCTYPE xcarML><xcar> <mplayer_plugin> <currentDir value=\"/mnt/newmaxtor2\" /><mplayerExe value=\"/usr/local/bin/mplayer\" /><mplayerArgs value=\"\" /></mplayer_plugin></xcar>";
   return CfgFile;
}

it was complaining about not terminating the "

**bigb** · 04-24-2004, 01:39 AM

Yea, multi-line literals are depreciated.. kept complaining here, but just warnings..

Thanks for the fix..

**hijinks21** · 04-25-2004, 11:26 AM

i've been working on a dedicated client/server client for file mirroring and right now I have a client sending a dir to a server and the server seeing how many files are in that dir and every dir under it.. then the server sends back the file count.

bigb.. i might need some help on sending data over a socket.. i will try to figure it out.. if not i'll catch you on IRC or AIM

**bigb** · 04-25-2004, 01:17 PM

No problem man.. I'll be here working for a good part of the day on XCar..

After I finish the mp3 thing, I'm going to start re-doing our widget set. (custom widgets).. (something that will greatly improve how things look)..

**jbors** · 04-26-2004, 01:29 PM

Guys,
I see some good progress along a way you're going. I wasn't following the whole thread but see that you use QT and X. Not sure why you've made that decision, but it is really makes things worse especially for the start up times. X is not well structured, has many bugs and _extremelly_ heaviweighted and slow. I would suggest to use XDirectFB or DirectFB directly. 500Kb, all accelerated and simple...

Also. Using C++ does not give you flexible enough component model comparing to some other languages( tcl, python, perl ). So you may end up with using the external interpreter( tcl, python, perl ) to allow user to customize without the need for C++ code.

Regarding the MPlayer I think that using it is not very good for portability and embedding purposes. Even though the player itself is just a state of art.

Anyway I'm really impressed by the progress you've made. Good job.

Bors/

**bigb** · 04-26-2004, 02:50 PM

Originally Posted by jbors

Guys,
I see some good progress along a way you're going. I wasn't following the whole thread but see that you use QT and X. Not sure why you've made that decision, but it is really makes things worse especially for the start up times. X is not well structured, has many bugs and _extremelly_ heaviweighted and slow. I would suggest to use XDirectFB or DirectFB directly. 500Kb, all accelerated and simple...

We actually decided on that due to the number of developers that are used to such an enviroment, the ease of programming, and the Qt toolset allows us alot of very easy to use tools that someone w/ basic programming knowledge could do what they wanted.. XDirectFB which I have used before does have it's issues as well.

As far as the startup times, we are looking to make this a live CD type setup w/ hibernation, which would cut down on the load times, even with X startup times..

Also. Using C++ does not give you flexible enough component model comparing to some other languages( tcl, python, perl ). So you may end up with using the external interpreter( tcl, python, perl ) to allow user to customize without the need for C++ code.

Using interperated languages like tcl, python, and perl are great for some things, but lack alot of what we need. Portability is something we'd like to do (at some point), and using Qt gives us a serious advantage when trying to do that. Not only does Qt port very well, it also integrates (w/ a lil love ) into MSVS IDE, which allows Win32 developers to also develop for XCar..

Customization won't be much of a problem without the use of C++ code. Of course plugins are created in C, or C++, but their skin engine(which had yet to take full form) is based on XML. If you care to checkout the rchandler, we use XML to control how portions of XCar handle specific functions, such as video, audio, etc.. No need for C++ at all.

Regarding the MPlayer I think that using it is not very good for portability and embedding purposes. Even though the player itself is just a state of art.

Hmm, on Linux what would you suggest we use? As far as I can see no other player supports the amount of options, and simply "it just works".. It allows for VERY easy embedding w/ the -Wid and -slave switches, and plays just about anything..

Anyway I'm really impressed by the progress you've made. Good job.

Bors/

Thanks for the good comments.. Good things are to come, hope to see ya involved with our decisions..

**jbors** · 04-26-2004, 04:27 PM

Originally Posted by bigb

Using interperated languages like tcl, python, and perl are great for some things, but lack alot of what we need.

You're right in some sense. I'm talking about Python as a glue for low level primitives. I have attended presentations about what people doing in high level languages and how fast it is. Those are pretty complicated apps and very extensive in calcs and visuals.

Doing good interface( pluggable and controllable ) in C++ is really tough thing to accomplish and I'm just trying to preserve your positive energy for something more productive than just writing a lot in C++.
And if I start doing it I would use existing packages( XINE, MythTV ) as a basis...

BTW: I'm going to release PyCar with these additional features( to 1.0.0-pre2 ) in 2 months:
- DVD playback( HW accelerated for EPIA-M )
- FM/XM radio
- Graphical LCD support
- CD/DVD Rip
- OBDII

Everything glued by Python with the same code base for Lin/Win.
8Mb Linux distro for EPIA-M/II- 6000. 25 sec boot up time( with LinuxBIOS installed ).

Bors/

**bigb** · 04-26-2004, 07:37 PM

We had a user here (hijinks) writting an app like this in Python, and found it to be too slow. Graphic and GUI functions are often very slow in languages like that. Including Java, etc..

As far as our issues w/ writting in C++, and creating a pluggable interface, I think we're on a pretty good track as far as that goes. Granted, we do have a greater boot time, we're looking for good ways to lower that number. The same user that did the Python program is now a developer w/ XCar, and has experience creating distro live cd type installs.

As far as boot speed, I use linux (rh9) w/ hibernation mode, and I recover in about 30 seconds. Of course that number is greatly increased on an initial boot. So I think we're on about the same lines. And I have some of the more powerful tools that a major distro comes with.

Also, we're looking to leave this as an open framework, (or as open as possible).. So Python just woud'nt cut it. It's lacking in places where C, or C++ is an obvious bonus.

We'd like to be able to have visualizations, etc, and no offense to Python, your, or it's developers, but PyOpenGL is a little pathetic.. It's slow as all can be, due to it's wrapping, and re-wrapping. It'd work great for a simple visualization, but we're looking to be able to use WinAmp vis, and we would'nt be able to do that with Python.

For what was originally said needed to be done, I beleive we made a good choice. Python's speed issues, and various other wrappers, etc for things that commonly need to be done in a system like this just don't cut it.

**bigb** · 04-26-2004, 07:39 PM

And please don't get me wrong, I am not knocking your system, or what you have done at all, it's really cool. Just for what we're looking to do, an interpreted language isn't going to cut it..