Page 3 of 32 FirstFirst 12345678910111213 ... LastLast
Results 21 to 30 of 315

Thread: New Linux Project (windows maybe)

  1. #21
    Constant Bitrate
    Join Date
    Mar 2004
    Posts
    117
    Currently I have this :
    http://www.crystalfontz.com/products...CFAH1602BTMCJP

    In my car. It does not come on only at night, though I'm sure adding support for this is not a problem, since I already have the communications part of the software done for it. As far as the screen dimming. My software right now will dim the screen(not the backlight of the screen, but basically by putting a slightly transparent "block" over the screen. Which helps to kill the ammount of light coming from the screen.

    Mine does this automatically after 30 seconds of non-use, after 6pm and before 7am. It does help alot when driving at night, and may be somewhat of a solution for some of you. Although it should also be very possible to have an output(using LPT ports) to kick on and off a relay for the screen power. Thus allowing someone, instead of dimming a screen, to turn it off after a certain ammount of time. (this is something I had planned on my current software, though after deciding to re-write a solution, it will be implemented.)

    That's all folks, still working on a little framework thing here, will be posting in a few hours. Hopefully we'll get some good response.

  2. #22
    Constant Bitrate
    Join Date
    Mar 2004
    Posts
    117
    Ohh, how bout "XCar" for a name? lol.. I'm a little tired of calling it "the software to be developed".. haha.. Anyone like/dislike? New ideas?

  3. #23
    Constant Bitrate
    Join Date
    Mar 2004
    Posts
    117
    Ohh, and "XCar" is because this is mainly being developed for the X Windows system.

  4. #24
    Raw Wave hijinks21's Avatar
    Join Date
    May 2002
    Location
    Albany, NY
    Posts
    1,803
    sounds good to me
    '98 Explorer Sport
    http://mp3car.zcentric.com (down atm)
    AMD 800mhz 192megs RAM 60gig hard drive 9 inch widescreen VGA
    80% done

  5. #25
    Constant Bitrate
    Join Date
    Mar 2004
    Posts
    117
    Okay. Now another question. I was thinking of a good way to do "plugins", etc. And I guess we need to decide how this is going to be done. Shared Libs, server/client based, custom design?

    I was thinking if plugins were "standalone" apps, that the main program would launch, and kill on it's own would allow us to have greater portability. Say a windows user wants to use MapPoint for his GPS software, XCar could launch the executable, and find the pid of the process after launch, allowing it to kill/minimize/etc the application?

    Downsides I could think of were the need for every application to be larger than it has to be. The upsides are alot greater expansion w/o problems.

    Reason I was thinking about this, is I was trying to think when doing the plugin support what would be needed from main application. Would it need access to the audio channels, would it need direct video access, etc.. and I can't think of one reason why it would. If applications were independant, creating "plugins" would be a hell of alot easier for those that don't have alot of C++ knowledge, and are just learning.

    Of course, even in this setup, we'd have to have some shared libraries, etc to allow a plugin to get information from the main program. (like current volume level, status, etc). Though that is very easy to do. (either have the main app listen on a specific port # for incoming connections, or a simple shared library to gather info like that).

    Any ideas out there?

  6. #26
    Constant Bitrate OdysseyPC's Avatar
    Join Date
    Oct 2003
    Location
    ACT, Australia
    Posts
    114
    I've been developing a similar idea (plugins, modularity) for the Windows platform for about 2 months now and am starting to get to the point of a workable/feasable foundation.

    It's largely modelled on the way Windows handles it's services, where services in my case are plugins/modules. I have a main program that replaces the explorer shell, on initial setup you set the modules you wish to load on startup (e.g. menu, music, gps, relay controller, lcd controller, etc). The plugin modules themselves are ActiveX executables, but don't run standalone.

    Communication between modules is provided through messages being sent and coordinated through the main program (i.e. server/client). Broadcasts are also possible through this method. One thing this method requires however is a reasonable amount of structure all modules must contain the plugin skeleton (that is provide the appropriate methods that the main program expects).

    I hope this is gives you some food for thought, I must say that I am new to Linux so I don't how you could implement the following, but who knows. Good luck.

    PS. (Not to encroach on your posts ) If anyone is interested in providing some assistance/cowriting then let me know. Must be fluant in VB, have concept of structured coding. This will be open source, but still moderated.
    Caputer Mk. II
    '02 VX Holden Commodore Series II Executive
    MII12000, 512MB RAM, 60GB HDD (5400rpm), 16X DVD, TS200V
    Morex 60W DC-DC, Custom S/SDC
    OS/Software: Developing...

  7. #27
    Constant Bitrate
    Join Date
    Mar 2004
    Posts
    117
    Basically, what your doing is what on Linux is "shared libraries". Your .dll files, are our .so files. Same deal. All plugins that would be created if we used this method would have to use a "skeleton" format that is required by the main application. The application then loads or unloads specific plugins based on that. Pretty easy stuff, though for alot of what we'd be doing, it's seriously overkill.

    Example :
    MP3 support. Does our main application handle all audio related information, then it's up to a plugin to use it? Or does the plugin handle the audio drivers, and just tell the main application what it's doing?

    I'm not opposed to EITHER of these ideas. Just need to get a handle on what is going to do what. The main app could handle everything, problem with that is, when someone goes to make a plugin, there is so much more they'd have to know to actually get it to work.

    EDIT : And is it me, or is everyone doing their own thing? haha.. If that's the case, I'll just stick with what I have now.. haha, custom brew software.

  8. #28
    Variable Bitrate
    Join Date
    Dec 2002
    Location
    Chico, Ca
    Posts
    315
    I think a single approach would be a better idea if we want this thing to really go somewhere. I'm not knocking the guys who do their own coding but there are a lot of talented programers out their who might want to help out with this. It also breaks up the workload to make things less intensive.

    I think we should spend some more time hammering out the details of what we envision this thing to do. Get this hammered down and then split the project up to the people who want to take on a piece.

    So far it seems that hijinks and bigb know what they are doing when it comes to Linux and programing. Anyone else feel confident to assist in this project? If so, post what you think you would be able to work on.

  9. #29
    Constant Bitrate
    Join Date
    Mar 2004
    Posts
    117
    That's what I was thinking. If we/I designed a "server" type application that allowed outside software to control, and get status from a main application (sort of like a telnet challenge/response) type thing, then outside software could very easily, and very quickly be implemented from various programmers. It would'nt be the type of thing where someone's software would be locked into ours either. If someone wanted to use "xxx user's" MP3 module, they could, with or without our software.

    Our software would simply allow a very easily skinable, and plug-able interface for people. Of course it would be open source, so if any one of the developers wanted to use our skinning methods, they could very easily.

    This would also allow people to always have an option. They want to use a new GPS program for Linux, or Windows that just came out, they could. Without us having to do anything to support it.

    The downsides to this : More memory usage, etc, but that is really not too much of an issue anymore w/ the larger ammount of ram that goes in most machine's anyway.

    There would be alot of information that could be passed back and forth between specific programs as well to allow them to communicate a little more openly. I have already started ripping alot of the code for my current software apart to create certain "plugins" for this new idea. Such as relay control, mp3/video support, etc.

    Current framework of the new software will be 2 different things, in which are both portable between Linux, and Windows, and both work pretty well on either system... Qt, and SDL. Only problem that I see coming up is getting access to low-level audio on a Windows system. It's not easy, or fun. Linux is easy, using the various drivers (OSS, Alsa, etc.. ) but I am trying to keep this 100% portable.

    Anyone have any ideas? Things seem to be going a little slow, maybe if I post up some serious info, code, examples, or something it'll pick up? Dunno..

    I'm going to assume after a framework is laid out, alot of my time is going to be taken reverse engineering a map software to allow us to use GPS natively without the need for "downloading maps" before driving, etc. As some of us don't have wireless connectivity in their cars(I do, but still)..

    Anyone feel like coding? lol.. C++ would be nice, C will work. Even perl scripts are good, (as I can port them pretty easily to C++). I know your thinking "but perl runs on Windows too".. I know it does, but someone would have to download the runtimes (perl.exe) to get it to function on their machine. I'm also trying to keep the size/dependancies down to a minimum.

  10. #30
    Raw Wave hijinks21's Avatar
    Join Date
    May 2002
    Location
    Albany, NY
    Posts
    1,803
    as you put code out there.. people will come to develop. I've manage a few open source projects at the start and it was very slow to pick up steam.. then boom.

    I think if you/we/or anyone makes a good core that handles all the user events and allows them to be passed to whatever module(s) are running then it'll make it so people can contribute modules easily and also it'll make developing modules a lot easier.

    That is just my experience though
    '98 Explorer Sport
    http://mp3car.zcentric.com (down atm)
    AMD 800mhz 192megs RAM 60gig hard drive 9 inch widescreen VGA
    80% done

Similar Threads

  1. Linux App Progress (windows also?)
    By hijinks21 in forum Software & Software Development
    Replies: 0
    Last Post: 09-15-2003, 01:33 PM
  2. Anyone using an operating system besides Windows or Linux in their car?
    By Squeezer in forum Software & Software Development
    Replies: 1
    Last Post: 06-20-2003, 12:33 PM
  3. Linux or Windows
    By lrat in forum Off Topic
    Replies: 2
    Last Post: 12-01-2002, 07:43 AM
  4. Windows or Linux?
    By kevmo in forum Off Topic
    Replies: 5
    Last Post: 10-19-2001, 08:11 AM
  5. Windows vs Linux vs DOS
    By SeenaStyle in forum Software & Software Development
    Replies: 0
    Last Post: 04-07-2000, 03:28 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •