On 3 Mar 2002 at 12:12, Michael Nordstr�m wrote: Hi Michael,
Thank for the info! > > >get an error about not being able to access the Palm Desktop software > > >when I start the app, open the data for a channel, etc. > > > > I will check that out. Must have missed a condition somewhere. > > I found the problem after a quick look at the source code. The file > palm_installer_msw.cpp was used instead of the gtk version. After > changing that in the Makefile I get an option for a pilot-xfer > connected device. That makes good sense. On the source code TODO, is to split the current OBJECTS= into a list of common objects, as list of GTK objects, and at the end, OBJECTS= $commonobject $gtkobjs. This is similar to the wx makefiles themselves. This I think will help avoid this sort of stuff from happening, plus also make it more clear what code is shared and what is GTK. Sound OK? > The directory destination still doesn't work, though. The seems to > happen when the created Plucker document doesn't have a full path, > i.e. the program can't find it since it expects the document name > to use either a full path, plucker: or file: settings. I'd suggest > to change the protocol_filename_to_filepath function to also check > if the name doesn't start with '/' and if so prepend the pluckerdir > path. Makes good sense. Nice call. Hadn't considered that after removing the plucker: protocol from the start. Will put that in today. > The filename setting still has problems; it does get a valid name, > but if the given filename is the same as the section name it will > change it back to be autogenerated (which will change it from being > saved in PLUCKERDIR to be saved in PLUCKERDIR/channels/<CHANNEL NAME>/). > The reason for this is the check in channel_dialog.cpp (line 445). > Why do you change it to use autogenerated names if it's the same as > the section name? I was looking at that the other day too. It can easily be changed to only choose autogenerate if the doc_file=PLUCKERDIR/channels/<CHANNEL NAME>/<CHANNEL NAME> Creation of a new channel via GUI puts creates a new channels doc_file=PLUCKERDIR/channels/<CHANNEL NAME>/<CHANNEL NAME> so they are fine that way. Channels that are created and manipulated entirely by GUI are fine. I guess would be the no doc_file key exists would also need to be handled in some way. What do you suggest there? Probably better not to have a mix of some channels outputting without user awareness to PLUCKERDIR and others to its channel subdirectory (but still let user specify PLUCKERDIR if desired). The reason why they are given a output filename that is based on section name is that it prevents overwrites on Mac/MSW palm installations, as all the files to be installed are sent to a single directory and wait there to be sent to PDA. It is possible to output the pdbs to PLUCKERDIR, but this becomes a horrible mess on MSW, as now the .pdbs are mixed in with the Plucker executables. Was put in channel subdir so can wipe off everything with much less worry when deleting a channel, by deleting its entire channel subdir. I am easy going to whatever you think would be best there. > Another bug is that it adds a new NEW_CHANNEL_TEMPLATE to the list > everytime I run the program. Seems to be because a "_<NUMBER>" is > attached to it. Should probably handle the template differently. Hmm, I only get one. That swatch in plucker_controller.cpp needs to be updated anyways, so I'll do that up before doing the rest of this bug up. Off the top of my head, the flow of the current way is to check somewhere in the startup to see if a NEW_CHANNEL_TEMPLATE section / subdir exists, and if not then create it. Currently this is mixed in with the adding a channel (and adding a channel autogenerates a new section name by stripping illegal characters, dropping it to 25 or so chars (Mac stops at 31 chars, so leave some room for some high digit numbers) and appending a number to end of it ). But I think it is better to pull it out into its own function for clarity and better mainenance. Also, For the zero-width section column, I put it as column zero (and changed all the inserts), but then realized that only the zero column can carry an icon, so if zero column is hidden, the icons all disappear making it look pretty bland, so as put back again. I asked Vadim about it, here is his reply: --------- RO> On the GTK port, is there some problem with either wx or GTK that RO> makes the header of a zero width listctrl column write the header name RO> across the ctrl into the column to the right. Seems like the clipping rectangle is calculated incorrectly in this case. RO> Is this a known issue with either wx or GTK? Any solutions or RO> workarounds? It is almost surely a bug in src/generic/listctrl.cpp - I don't have the fix right now but it should be quite simple to correct this. Any patches, as always, are greatfully accepted. --------- Robert (Roebling) added: the problem could be that a zero width (clipping) region is "empty" and therefore possibly ignored in wxClientDC. I don't have any test here, but I usually use wxRegion::Empty() for testing regions - which might be wrong in this case. --------- It's probably better to just fix this bug in the toolkit than to hack around it. If you have a moment and want to take a look at listctrl.cpp and see if anything jumps out, this might be the best solution. I don't have a GTK to test it on, but if you aren't up for it I can probably compile the generic listctrl and take a look around and find the bug. If take the hack route, can it be a single pixel column (main_listctrl.cpp, line 210:) InsertColumn( SECTION_COLUMN, _( "Section" ), wxLIST_FORMAT_LEFT, 0 ); to InsertColumn( SECTION_COLUMN, _( "Section" ), wxLIST_FORMAT_LEFT, 1 ); or a fuller size column? if so, can #ifdef around it for GTK in the meantime. Best wishes, Robert
