Re: Further dev work?

Bug tracking is: http://bugzilla.gnome.org/browse.cgi?product=gnome-pilot

I've started looking at some of the source code, and as a sort-of test,
tried to find the code that handles files being drag&dropped onto the panel
applet. My assumption was that it would be in
http://svn.gnome.org/svn/gnome-pilot/trunk/applet/pilot.c but I haven't
found it. Am I looking in the wrong file, or do I just need to look closer?

On Dec 27, 2007 7:48 PM, Evan <[email protected]> wrote:

> Is libusb's lack of support for some Palms something specific that is
> being resolved, or is it more of a fundamental design issue?
>
> I have a Z22 which doesn't support external storage, so I didn't know that
> you can sync files directly to sd cards in the palm; I was under the
> impression that you had to plug the sd card in directly and copy files with
> the file manager. Taking this into consideration, perhaps have the option
> that, depending on the model and what it supports in terms of external
> media, provide a choice of where to install files (for each file installed)
> and block certain file types for unsupported devices.
>
> I was referring to par, and while it isn't "purty", it does do the job.
> Refining the process can be done at a later date, and figuring out why it
> works might help us in reverse-engineering other SplashData formats (barring
> any legal roadblocks).
>
> My (probably faulty) concept for auto-detection works like this:
> -ask the user for their model (Z22, Treo xxx, etc.) and connection type
> (USB, IR, Network, etc.)
> -have a database of each model, how it connects etc.
> -if necessary, load the visor module and add it to /etc/modules
> -if model X is given, then try the sync with each of the 4 or however many
> /dev files it could be until it gets a sane response
> -using the /dev file in the previous step, do a proper sync
>
> There can't be that many new models released every year, so it shouldn't
> be hard to keep the database up-to-date. There probably is a problem with
> this, but I can't see one off the top of my head. Unless the device it uses
> depends on more that just the type of port and palm model?
>
> I assume you mean the source code at: http://live.gnome.org/GnomePilot
> I'll take a look at it as soon as I get the chance.
>
> Evan
>
> PS what bug-tracker does gnome-pilot use?
>
>
> On Dec 27, 2007 5:15 PM, David A. Desrosiers <[email protected]>
> wrote:
>
> > On Thu, 2007-12-27 at 17:01 -0500, Evan wrote:
> > > I know it's fairly stable, but it's getting out-dated. I've heard
> > > various ideas being kicked around that I think are necessary but that
> > > haven't gotten any work:
> >
> > >    - migrate from the visor module (deprecated) to hal in order to
> > >    support newer devices while maintaining support for older ones
> >
> > Not libusb does not support all USB-connected Palm devices, which is why
> >
> > libusb is not the default for the library subsystem (you have to build
> > it with libusb support and do some other setup to get it configured on
> > your system).
> >
> > > - prevent installation of non-prc/pdb files, as they cause errors and
> > >   lock-ups (this should be really easy?)
> >
> > This too is going to be a problem with NVFS and external storage. I
> > regularly sync non-Palm files to my SD card using pilot-link's tools, so
> > forbidding them entirely isn't a good option.
> >
> > Providing a logical method to send non-PalmOS files to external storage
> > (or error out) is a better solution.
> >
> > > - automatically wrap pictures in pdb containers to make them readable
> > >   by splash-photo (somebody has already written a program to do this
> > >   and released it under the mozilla licence, just requires some
> > >   integration)
> >
> > Last I knew, SplashData did not release their storage format or provide
> > any sort of API to write to. Do you have different information on the
> > matter?
> >
> > There is a way to do this with par, but it's not purty..
> >
> > ./par c -a "stream" foo.jpg.pdb foo.jpg Foto Foto foo.jpg
> >
> > > - run an auto-detect to determine which device, connection speed, etc.
> > >   to use rather than making the user enter it manually (should be
> > >   easier when hal migration is complete)
> >
> > Horse => Cart problem
> >
> > How can you auto-detect which device you have, if you don't know the
> > right way to talk to it in order to connect and query that information
> > from the device?
> >
> > Believe me, if this was easy, we'd have solved it years ago. The problem
> >
> > is that we have no documentation from any of the vendors, and the
> > devices they continue to ship, seem to have their own little "quirks",
> > which some work on some endpoints, others want other endpoints, and the
> > timing and speeds are completely unpredictable (based on Palm-side CPU
> > speed, host CPU speed, connection type, driver subsystem, usb host
> > controller, and so on).
> >
> > > I can program in java and .net and I'd be willing to learn c++ or
> > > whatever to implement some of these, but I don't know where to begin.
> >
> > Jump in, read the code, and get started. It's all in C/C++ anyway, so if
> > you know Java, you should be able to understand the code enough to close
> >
> > existing bugs, or help implement features by adding patches to the
> > existing codebase.
> >
> >
> > --
> > David A. Desrosiers
> > [email protected]
> > Skype...: 860-967-3820
> >
> > _______________________________________________
> > gnome-pilot-list mailing list
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/gnome-pilot-list
> >
>
>

_______________________________________________
gnome-pilot-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list