CarPal - Modular Cross-Platform Frontend - Page 2

kev000 · 05-10-2009, 05:56 AM

Quote: Originally Posted by Tidder

Just because you do it in one area on the forum wouldn't mean we would have to start doing it everywhere...

I like the skin Malcom, good job for a first (third?) try.

yep, skin is looking much better. The gauge numbers are a little squished though...

malcom2073 · 05-10-2009, 01:37 PM

Update: I noticed the visual c++ 2008 runtime may be needed to run CarPal:
http://www.microsoft.com/downloads/d...displaylang=en

malcom2073 · 05-10-2009, 03:36 PM

I've posted an update to V0.30. Embedded applications are now working, and iGuidance is CONFIRMED as working. This means CarPal now has navigation! Woo!... Dunno if anyone else is as excited as I am. This has also been tried out on a FitPC, the 500mhz one and confirmed as being "very quick" to quote Tidder. I will be working with him to ensure that CarPal remains quick on even the slowest hardware.

Enforcer · 05-10-2009, 04:01 PM

Quote: Originally Posted by malcom2073

3: Expandability. CarPal is completely modular and plugin based. New functionality can be provided by simple to write (if you know c++) plugins. I am working on a .net interface to allow c#, vb.net and c++/.net users to write plugins for this as well.

Get me some example plugin code to work with (VB based )and I'll see if I can get my plugins to work for this.

malcom2073 · 05-10-2009, 04:10 PM

Quote: Originally Posted by Enforcer

Get me some example plugin code to work with (VB based )and I'll see if I can get my plugins to work for this.

As I said I'm still working on the .net functionality, I've gotten one way communication working (CarPal->.net) but not the other way. I'll move that closer to the top of the list now that embedded apps are working and see if I can't get it running.

The entire basis behind the plugin system are messages that have several parameters. I'll list them here just so you get an idea what you'll be dealing with.
Sender - name of the plugin sending the message
Target - target of the message. Plugin name, window name, or "core"
Class - top level "Type" of message. For example this could be "window" to deal with window commands, or "playlist" to deal with playlist commands.
Method - Actual command to run, eg: show for a window class, or play for a mediaplayer class.
Arguments - Each message can have a list of arguments as strings. This is used for whatever you want. For instance, the MediaPlayer uses this to send a list of current playlist filenames.

The system is also event based, you can "subscribe" to events by sending an IPCMessage to the core, and you will recieve an IPCMessage when that event is thrown. I will provide a list of what events are provided by what plugins once I get the .net interface up and running.

What do your plugins require in the way of external information? I can make sure the interface is there.

Enforcer · 05-10-2009, 04:36 PM

It all depends on how you plan on how you plane on incorporating plugins.

So far I have seen 2 (possibly 3 ways)

1. RoadRunner's way, which is basically the most integrated as the Frontend handles the skinning etc and you just pass label, button, indicator and slider information etc and also commands ( Plugins can also interrupt and change commands and label information).

2. Centrafuse's way, in which the plugin handles the skining and can send and receive commands. (it's just above embedding an app)

3. Embedding Apps, Plugin/App handles everything and can't send commands or label information to main program.

malcom2073 · 05-10-2009, 04:55 PM

Atm the c++ unmanaged plugins are set up to run RR's way. It is possible to write them to operate like CF where they create their own windows, but I feel that the first way is the best. I'll probably continue the same style interface for .NET plugins unless there is a need for more flexibility.

Enforcer · 05-10-2009, 05:25 PM

Going RoadRunners way is preferable

Tidder · 05-11-2009, 01:37 PM

Yanno with as functional as this frontend is getting... it may be high time you requested your own CarPal area in the frontends section.

malcom2073 · 05-11-2009, 04:55 PM

Quote: Originally Posted by Tidder

Yanno with as functional as this frontend is getting... it may be high time you requested your own CarPal area in the frontends section.

We don't need no steenkin subforum!

Tidder · 05-12-2009, 12:16 PM

If people are gonna start downloading and using... they'd need, and you'd want, a place that's easy to view/manage to start knocking out bugs. C'mon now.

malcom2073 · 05-12-2009, 04:52 PM

Psh....

Speaking of bugs, Enforcer: I got .net interop working. I'm just ironing out the specifics of the interface and then I should be able to upload a new version. Basically in VB you would have to add a reference to my InterfaceClass.dll file (which is provided with CarPal). Then you create a class that implements the interface InterfaceClasses.IPlugin.

I'll provide a sample VB.net and C# plugin to give you the idea. Probably have it register to receive an event, perhaps have it register its own event. Possibly even have the ability to play/stop a song based on a skin button press.

Sonicxtacy02 · 05-12-2009, 05:00 PM

i should have ya base skin available tomorrow mike.. i havent forgot ya

User Name		Remember Me?
Password