Re: Plucker Viewer (hires, v20030222-am)
On Fri, Apr 04, 2003, Adam McDaniel wrote: > Well, you cannot filter by types, but you can sort. You can "filter" the documents on the external card by removing it from the device ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bookmarks in viewer - anybody there?
On Thu, Apr 03, 2003, Marcin Marsza?ek wrote: > So first od all thanks for this great piece of software :) Well, I am the maintainer of the viewer, but I'm not the only one working on the viewer (and the viewer is only one part of the Plucker project), so there are many others that also deserve your gratitude ;-) > It is not so easy for me to reply here (I prefer to receive digests and it > seems that I can't request individual messages), but OK, if you wish so. The reason I rather see Plucker questions on the mailing list than sent directly to me (or the other Plucker developers) is that when I get a message my answer will only benefit one user while the answer to a question sent to our mailing list can benefit many more users. It also makes it possible to get input from several users/developers. > Do you plan to implement bookmarks in the nearest future? Right now I would like to release a first beta of a 1.4 version and that would not "allow" any major new features. It could be added to the 1.5 (unstable) version, though. Actually, external bookmark support could be a "simple" feature to implement for someone that wants to start working on the viewer code, since some of the named anchors support could be re-used (at least I hope that will be possible:) > If you need some documents containing internal bookmarks and/or > code generating those documents, I can of course provide it to > you. What you could do is to add a feature request (e.g. "Add support for external bookmarks") at http://bugs.plkr.org and attach a document (or two) with external bookmarks. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bookmarks status
On Mon, Mar 31, 2003, Marcin Marsza?ek wrote: > In DBFormat I can see "not implemented yet". But reader has bookmarks > support. The DBFormat document says that support for *external* bookmarks is not implemented yet. I have suggested a possible format for bookmarks added by the parser, though, but I don't have any immediate plans to add support for it to the viewer; I have enough things in my TODO list at the moment. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bookmarks in viewer - anybody there?
On Wed, Apr 02, 2003, Adam McDaniel wrote: > I'm not sure on how bookmarks are being used, but I did find something > odd.. There is nothing "odd" about it; check the DBFormat document and you will see that I have specified that external bookmarks are not supported yet. I wrote that a LONG time ago and since no one showed any interest in adding support to the parser I worked on other feartures for the viewer instead... > For the record, just by looking at the viewer code, bookmark's are > currently being handled solely by the viewer from within > bookmark.c. It actually stores the data within the specific document's > metarecord (Ie, Plkr-.pdb) External bookmarks would work in a completely different way and wouldn't have anything in common with the "internal" bookmarks. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bookmarks in viewer - anybody there?
On Wed, Apr 02, 2003, Marcin Marsza?ek wrote: > When are they planned to be implemented in the viewer? Whenever someone volunteers to add it. It's not that complicated to add, but it still requires someone to do it ;-) > Who is maintaining the viewer code I am. > - maybe I could reach him privately by email? Maybe you could, but this mailing list is a better solution ;-) > I see that my previous question was too long, so I decided to > repeat it ;-) Sorry for messing around, shouldn't happen again. Nothing wrong with your previous message (I just didn't have time to reply until now), so no reason for you to apologize. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Global Search in Viewer ?
On Fri, Mar 28, 2003, David A. Desrosiers wrote: > I'm not sure how in-depth Matto's search was The subpage search that Matto added is only an "extension" to the normal search function. Actually, when I cleaned up the code I was able to remove quite a lot of code just by reusing the "original" search functions, i.e. the subpage and "in all pages" search options are very similar in concept. To search in all Plucker documents will require a quite different solution. > I'm not sure if it searched ALL documents that had > the CreatorID of Plkr though. It doesn't. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Makefile on MacOS X (was: Plucker 1.3 features, building and suggestions)
On Tue, Mar 18, 2003, George Harker wrote: > I've got a copy of prc tools for my platform (mac os x) and I've had no > luck thus far. I think I'll need to rewrite the makefile :( Well, first you need a Makefile to rewrite ;-) > I can't just type make, I have to specify make -f Makefile.in Makefile.in is just the "template" that is used by the configure script to create the actual Makefile. To create the configure script when using the code directly from CVS, you first have to run 'autoreconf' (if you don't have that program then I guess you have to install the GNU autoconf package, too) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: More table questions
On Wed, Mar 12, 2003, Laurens M. Fridael wrote: > struct.error: required argument is not an integer There is a bug report for a similar (the same?) problem in our bug database (#518). I assigned it to Chris, but maybe he hasn't looked at the problem, yet. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Mon, Mar 10, 2003, Bill Janssen wrote: > * I think I'd pick 80x80 as the default chunk size. That will waste memory; 80x80 might be OK at 16bpp, but I think the default size should be calculated in the parser and use bigger chunk sizes for lower bitdepths. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Deleting documents while set to Manual update
On Sun, Mar 09, 2003, Dennis McCunney wrote: > My suggestion was that if you tried to delete a document from the > list, and the delete failed because the document wasn't there, > removing the entry from the doc list was a reasonable action for > the viewer to take. Mike disagreed with me. C'mon, that is not a fair description. I didn't just *disagree* with you; I *explained* to you why it wouldn't be a good idea to implement your suggestion... > Deletes would be simpler if it were possible to simply delete the > doclist entries for files you have removed outside the viewer. If you don't remember what documents you have removed and still try to open one of them the viewer will indicate for you that the document isn't available. It won't crash or do anything else that could be considered a bug, so what is the problem? If you are really concerned about this then create a category for the documents you intend to delete, assign the documents to the category, and then make sure that category isn't selected; voila, the deleted documents are not displayed in the list any longer ;-) If you always categorize your documents then you could even use Unfiled for this... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Mon, Mar 10, 2003, Michael Nordström wrote: > I'm not sure you would even have to use a list to implement this... Actually, I think it would be possible to support "large" inlined images without making any changes to the viewer. If the parser would split the image and include the different parts in the Plucker document as several "normal" images after each other then the viewer wouldn't require any changes to support the large inlined image. Each individual image part would link to the same large pannable image. However, to support the much larger pannable image would require changes to the viewer, too. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Adam McDaniel wrote: > I've attached a diff as a preliminary implementation of > horizontally layering images. But that code only handles *inlined* images. An inlined image is not a problem, since you only draw the image and then "forget" it. However, to handle the large pannable version you would need something else and that is what I'm talking about. You can see my suggestion at http://www.plkr.org/list/2Q2000/0132.html Keep in mind that it was written in June 2000 and the idea would most likely need some changes... > Fortunatly, I see no reason as of why this would take up any more > memory this way then if there were actually that many images nativly > references in the document itself..., other than the linked list but > that's only temporary. The images don't take up any extra memory at all, since we don't have to "remember" anything for inlined images. I'm not sure you would even have to use a list to implement this... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Deleting documents while set to Manual update
On Sun, Mar 09, 2003, Dennis McCunney wrote: > The third option -- having the viewer only look for new docs in RAM -- > might be a nice addition. Add a feature request at http://bugs.plkr.org and I will attach a viewer to it that implements this... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Laurens M. Fridael wrote: > Images this wide will lead to gigantic PDBs, so in practice you > won't even go near this limit. The difference between Adam's suggestion (based on what he wrote; I haven't seen the code, yet) and my suggestion is not only about the image size, but also about the memory it uses to display the images. Let's say we actually have an image with a width of 30k pixels and e.g. a height of just 100 pixels. To display that image we would have to work with 100 1x30k images at the same time. Now, I haven't seen Adam's code, yet, but I would be surprised if it could handle such a (I admit, exotic:) case... If you split the image in both directions you would be able to display the same large image while using a much smaller amount of memory (hopefully, if my theory works in practice, only the same 60k we use today.) I know from past experience that Adam has a different view than me when it comes to the viewer's memory use; IMO, we should use as little memory as possible to be able to support also older devices and not only the latest and greatest ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Laurens M. Fridael wrote: > Then what's the maximum width of an image? Whatever that fits within the 60k limit and has a height of 1 pixel, i.e. it also depends on the bitdepth how wide the resulting image can be. However, I kind of doubt there are any "interesting" images that have a height of 1 pixel ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Adam McDaniel wrote: > Well, I don't see any problem in creating a single image thats 1000 > pixels wide and 1 high. Ofcourse, the altmaxwidth/altmaxheight value > would cap any runaway issues like that. In other words, you are replacing one limitation with another (i.e. there is a limit to how wide the image can be.) The only solution that will be added to the viewer is a solution that doesn't add new limitations (except for available memory:) If you check the archive you will see that my suggestion would be able to display images of any size (well, it will be limited by the size of the PDB, i.e. the number of records you can include:) I'm sure my suggestion from back then can be improved (I have learned a few more things about PalmOS programming since June 2000:) I did write some code back then, but since there was no response on the parser side (and I didn't really consider it to be that important to turn the viewer into an image viewer) I "suspended" that work and concentrated on other more important features... I did discuss it with Bill when I met him at PARC in 2001, but I'm not sure if he has put any more work into that particular feature (I haven't). Anyway, your current suggestion will not be used, but don't throw away the code. Maybe some part of it can be used for a solution that can handle images that have been split in both directions (maybe you would even be interested in implementing such a solution?) Still, it might be a good idea to wait until we know what would be possible to create in the parser... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: proposed solution to 64k image limitation
On Sun, Mar 09, 2003, Adam McDaniel wrote: > Now comes the problem. I have written the code in the viewer to > support this but I have no idea how to handle support in the python > parser Hmm, I can see more problems than just to make the parser split up the image; what if I have an image that is VERY wide? You solution depends on the width being of a "reasonable" size. I suggested a solution to this problem in June 2000, but (just as in your case) I needed a parser that could split the image into smaller parts... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Deleting documents while set to Manual update
On Sat, Mar 08, 2003, David A. Desrosiers wrote: > When you delete a document from the document library, Plucker can > set a flag on that database name _at deletion time_ removing it from the > preferences, so that re-entering the doclist won't enumerate them again, > correct? When you delete a document from the *document library* the entry will be removed regardless of whether you are using manual update or not. The "problem" is that when you remove the document using an external tool and has selected to use "manual update" mode the viewer won't find out about the "removed" document until you update the list (making it impossible for it to flag a document as deleted.) Actually, when you update the list of documents the viewer already set a flag for missing documents instead of removing them from the document list (the reason for this is to avoid losing the category info just because you remove an external card temporarily); documents will only be removed from the list when they are deleted in the document library... > Just one idea. Nothing bad about it, but when the viewer would have access to the necessary info it would not be necessary to do this (because the entry would have been removed) and when it would be great to be able to add this strikethrough the viewer wouldn't have the necessary info to determine which documents that have been deleted ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Why netscape? (was: Explode/unpluck error, fixed..)
On Tue, Mar 04, 2003, David A. Desrosiers wrote: > why do we check for Netscape? plucker/tools/explode/netscape4-plucker-helper.in /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: question about building hires under cygwin
On Mon, Mar 03, 2003, Eugene Y. Vasserman wrote: > $ make -I/usr/share/prc-tools/include/Core/UI -I/usr/share/... BTW, this only specified a few more directories that make should search for included makefiles... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: question about building hires under cygwin
On Mon, Mar 03, 2003, Eugene Y. Vasserman wrote: > /usr/share/prc-tools/include/PalmTypes.h:159: M68KHwr.h: No such file or directory Check where m68k-palmos-gcc looks for the include files by running, $ m68k-palmos-gcc -dumpspecs > running make and explicitly specifying those file locations in include > fails as well (same message - file not found): > > $ make -I/usr/share/prc-tools/include/Core/UI -I/usr/... Well, you can't add the paths that way. You would have to modify the CFLAGS setting to include those paths. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
To fry a fish... (was: GPL code question)
On Fri, Feb 28, 2003, David A. Desrosiers wrote: > want to ensure that your code is not "abused" by any commercial > entities (*cough*, fish, *cough* =). I think James Fisher (CEO at Bluefish Wireless) has made it quite clear that copyright only means something for "honest" companies. Actually, I thought the Bluefish mess was more or less resolved last year, but according to the mail he sent to us two days ago it seems like he might now also "abuse" our python parser (however, I guess he didn't really meant to reveal that in his mail:) Watch out Laurens and Bill N., if he finds out about the Java and C++ parsers he might try to abuse them, too. How anyone can still do business with that company is beyond my belief... /Mike -- "If we end up in court, I will bankrupt these guys." - James Fisher CEO, Bluefish Wireless Inc ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: GPL code question
On Fri, Feb 28, 2003, Bill Nalen wrote: > There would never be a need to come back to the original owner for > permission to do anything right (as long as it is kept GPL'd)? The only thing that requires permission is if anyone want to release the code under a different license; only the copyright owner can do that. Since Plucker will always be GPL there will be no problems... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Couple of db format doc suggestions
On Thu, Feb 27, 2003, Bill Nalen wrote: > Also, is the default category record working right? Have you seen any problems with it? > Do the corresponding categories have to exist already in the viewer > or will they be created if they don't exist and there is room in > the category list on the viewer? They will be created if there are free positions. > Also regarding categories, should they be type 8 (Bookmarks) or 9 > (Category)? Obviously it should be 9 (and that is also the case; see PluckerDocs.py in CVS line 108 and 2052), but the viewer doesn't really care what type you use. It is given the record number to where it can find the categories and when it access the record it skips the header of the record only looking at the data (i.e. the string of categories.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: fix prc-tools 2.x URL (patch to REQUIREMENTS etc)
On Wed, Feb 26, 2003, Michael Nordström wrote: > remove support for the obsolete A4 based version of prc-tools. Well, since I haven't seen any objections to this, from now on only prc-tools 2.x is supported (the code might build using Code Warrior, too) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: fix prc-tools 2.x URL (patch to REQUIREMENTS etc)
On Wed, Feb 26, 2003, John Marshall wrote: > BTW you mean --with-prc-tools=xyz rather than --enable-palmos etc :-). That's a good idea, but I think I will finally do something I have thought about for a long time now, i.e. remove support for the obsolete A4 based version of prc-tools. I have included your patch, though. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Cygwin filename case insensitivity in gcc (Was: patch to viewer/configure.in)
On Tue, Feb 25, 2003, Fringe Ryder wrote: > I was noting the different standards of the environments, not the > quality of developers. Nice try, but the fact remains that most of your message was nothing but an insult against free software developers and that is not the kind of message you should send to a free software project's mailing list. Maybe we should put up a sign somewhere saying "No Trolls, please!" Saying that "professional environments" are better is even more braindead than your include header file suggestion, though. Most of us have worked in many different kinds of "professional environments" and know what a nightmare they can be and what kind of code they produce. > (Your text editor should support such a thing. If it > doesn't, I'm sure most of us could suggest better tools for you.) So nice of you. Well, considering your suggestion on how to include header files I think I will avoid any more "help" from you... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Cygwin filename case insensitivity in gcc (Was: patch to viewer/configure.in)
On Tue, Feb 25, 2003, David Starks-Browning wrote: > One could ask whether the GCC option "-I/viewer" is > appropriate. There are reasons for why some of these options are included; one reason is to be able to build the viewer in a different directory than the source code is located in. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: patch to viewer/configure.in
On Mon, Feb 24, 2003, David A. Desrosiers wrote: > I'm not suggesting we move en-masse over to 2.53, but if > we move anywhere off of 2.13, the next jump is 2.53, not 2.52 or > earlier. Well, if the autoconf requirement is changed I will just have to change it back locally (I will update my current Linux system, but not before the end of March.) I'm a bit "negative" about making changes for no real reason; if there was a valid argument for why it is necessary to use 2.53 instead of 2.13 then I wouldn't object to it... > There's quite a bit of nasty bugs that have been fixed in 2.53 that > would cause detection of things to fail in 2.13. I've run into them with my > code here, but they probably don't affect Plucker at this stage, but they > might as we keep adding more and more dependancies to the configure checks. Or we might never run into them, since most of our dependancies are quite "simple"... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Cygwin filename case insensitivity in gcc (Was: patch to viewer/configure.in)
On Tue, Feb 25, 2003, Fringe Ryder wrote: > In such an environment, it would be understood that plucker/viewer > shouldn't be in the include path. That's a project file; inclusions of it > would look something like: > #include "../viewer/font.h" At first, I thought I should be nice and not say what I think about the "professional development environment" you seem to work in... However, hardcoding the path in the source code must be one of the most braindead things I have heard of. A month from now, you suddenly decide you want to reorganize the file structure; while we "lousy" open-source developers only have to change a '-I' compiler directive, you "professionals" will go through all your source code making these changes (maybe you are paid by the hour:) Still, I think we should avoid using filenames that are similar to system header files. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Table Compression
On Mon, Feb 24, 2003, Chris Hawks wrote: > You're more familiar with the uncompress code (and palm databases) > than I, so, how about this plan for uncompressing (possibly nested) > tables?? I have a very pragmatic view; if it works then use it ;-) It is always possible to improve (or even completely rewrite) the code later. > Uncompress creates a new record in the uncompress database, saves > the record # and returns the handle. OK, so far. > table.c locks the handle and callsGet UncompressTableIndex() in > uncompress to get the record #. This part I have some doubts about. I think it would be better to use the UID for the table record as an "index", i.e. the uncompress code keeps a map with the info, so that later when the table code wants to release a record it only needs to provide the UID. Just a matter of encapsulation (i.e. no one but the uncompress code really needs access to the record#) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Release plans?
On Mon, Feb 24, 2003, Laurens M. Fridael wrote: > What are the release plans for the standard, non-Hires Viewer? Is there > going to be a 1.2.x bugfix release (the category bug with memory cards comes > to mind) or is it going straight to 1.3? I have suggested a "release plan" to the other team members; as soon as they have voiced their opinion about the plan it can be made "official" ;-) Because I (by mistake) broke the 1.2 branch in CVS a few months ago making it kind of difficult to commit new/updated code to it, I don't think there will be a 1.2.x version. Instead we should release a 1.3 version that, after some beta testing, would be released as 1.4 (odd minor numbers indicate unstable versions, while even numbers indicate stable versions.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: patch to REQUIREMENTS file
On Mon, Feb 24, 2003, David Starks-Browning wrote: > Just trying to help... I didn't "complain" about you reporting this; only that I have more important issues to worry about (and that the docs usually are left behind until a new version is about to be released.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: patch to REQUIREMENTS file
On Sun, Feb 23, 2003, Adam McDaniel wrote: > Hey Mike, since it was you who mandated SDK5 as the minimum, I guess > you dropped the ball on making this change, eh :) Sure, blame me. Adam (a.k.a. Mr Everyone-is-running-PalmOS5-so-why-should-I-worry- about-keeping-the-hires-code-separated-from-the-non-hires-code:) knows very well why we had to make SDK5 mandatory... Anyway, the code hasn't been released, yet, so I can't say I worry too much about "bugs" in the docs. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: patch to viewer/configure.in
On Sun, Feb 23, 2003, David A. Desrosiers wrote: > We should also make the migration to AC_PREREQ(2.53) as well, as > mentioned last week or so, and deprecate our use of 2.13. The viewer will continue to use 2.13... I haven't seen any convincing arguments to why 2.53 should be the required version to build the viewer. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back button (was: Better support for future OS versions)
On Sun, Feb 23, 2003, Adam McDaniel wrote: > I only mentioned it becuase I noticed the 'back' button > flash on the screen when your option is disabled. If it is a problem on hires devices then add the UNUSABLE setting... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Back button (was: Better support for future OS versions)
On Sat, Feb 22, 2003, Adam McDaniel wrote: > I'm not sure if you intentionally did it this way, but did you > purposly decide not to put the UNUSABLE switch onto frmFullscreenBack > in viewer.rcp.in? I believe in the KISS principle, so I don't change more than necessary. If that gives the current result because of some side-effect then that is fine with me (I only wanted to see the *full* screen in the fullscreen form:) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Better support for future OS versions
I have changed the code in os.c to make it handle new OS versions better. Instead of only initialize specific features for the "found" OS version it will initialize *all* features up to (and including) the found version. This means that if e.g. a viewer that is built today would be run on a PalmOS 6 device in the future it will support all OS2 - OS5 features, i.e. it won't use OS2 as the default any longer... I also moved some OS dependant code from fullscreenform.c and image.c and added an option to disable the "Back" button and arrows in the fullscreen form (the back button is still available but not visible; if you tap in the lower left corner it will appear, though.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: "Creating Teenee Tiny Fonts in OS 5"
On Wed, Feb 19, 2003, Adam McDaniel wrote: > I agree, but I was thinking about just checking in the compiled .bin > codewarrior spits out as the resource. I would still have to say no, because there shouldn't be any "code" that can only be handled if you have access to a non-free tool. > I was reading in throughout the code in pilrc in how it compiles > fonts, and altering it to support extended fonts (aka double-density) > doesn't look all too difficult. Well, when there is a free tool (that also must run on Linux) that supports double-density fonts then they can be inlcuded in Plucker, too. > The inclusion of the .bin would only be a temporary measure until > pilrc official supports this anyways. Temporary measures have a tendency to become anything but "temporary." You have to understand my view on this; if there is a bug somewhere in the viewer I want to be able to fix it. However, if we start to include stuff that can only be handled by using non-free tools (probably also only running on Windows) then I can't do that... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: "Creating Teenee Tiny Fonts in OS 5"
On Mon, Feb 17, 2003, Adam McDaniel wrote: > In order to get this to work properly, you need a full version of > codewarrior handy to compile the resource (pilrc doesn't support > double-density fonts yet). Well, if it only works with CW then it shouldn't be added to the code base... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: recent CVS updates
On Fri, Feb 14, 2003, Adam McDaniel wrote: > - Add back on the scrollbar dynamic update for all lores and OS5 devices. Make it configurable. > - Viewer crashes when viewing a .pdb containing only an image. Works just fine on my TRGpro (and always have), i.e. it must be a hires issue. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Line spacing
On Wed, Nov 20, 2002, masakazu wrote: > May I add a feature to change line spacing in prefs panel? The code in the unstable branch is open for more or less any kind of new features. However, all features in the unstable branch will not necessarily make it into the stable version ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: newline in env
On Wed, Nov 20, 2002, masakazu wrote: > Is this a problem of the viewer or the parser? Run it in a debugger and you will find the answer to that question ;-) In other words, if there are "newline" function codes in the Plucker document then it is a viewer problem, but if no "newline" codes have been included then it's a parser problem. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Bulletin Board instead of Mailing List?
On Tue, Nov 19, 2002, TIM CONSTANTINE wrote: > It seems to me that a Bulletin Board for communication would have > some serious advantages over this mailing list: As have already been pointed out the "advantages" are already available for the mailing list. If you started to use a differet system for communication then I can point out one major disadvantage: - some core developers will be missing Now, some of you might think it is an advantage that I'm not there to complain about lousy mail etiquette, but in the long run you will still lose if core developers don't take part in the discussions. BTW, I find it a bit amusing that newcomers always are so quick to suggest that we should abandon the mailing list. Do you really think we would continue to use a mailing list if we didn't think it was a good way to communciate? ;-) Also, since I have all the message locally I can search in every mail sent to our mailing lists since '98 without going online and I wouldn't want to lose that possibility. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
OT: GNU based version of AvantGo (was: Back/foward/home function code)
On Mon, Nov 18, 2002, David A. Desrosiers wrote: > We shouldn't follow AvantGo, because we aren't AvantGo, and we > aren't trying to replace them. When investigating a bug report I found out that we are the "GNU based version of AvantGo"[1] ;-) BTW, don't download the Plucker document from the site (it's corrupt.) /Mike [1] http://oopsla.acm.org/fp/files/pda.html ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Back/foward/home function code
On Mon, Nov 18, 2002, David A. Desrosiers wrote: > Show me where in the HTML spec, pods:// appears as a valid protocol. Well, if support was added for the javascript version that Robert mentioned then it wouldn't be such a big deal to support pods, too. Can't say I understand the benefit of using these "history back" links, though; when you create a site you usually know what page it should go back to, so why not use that link from the very beginning? Using a "history back" link can never guarantee what page you will go back to. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Relocating to England (was: accesskey attribute support)
On Sun, Nov 17, 2002, Laurens M. Fridael wrote: > Moving as in "living there"? Yes. Cambridge will be my "first stop"; then it depends on where I can find an interesting job (I will never move to London, though:) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: accesskey attribute support
On Sun, Nov 17, 2002, Robert O'Connor wrote: > One possible solution would be to have a prefixing stroke to go into > accesskey mode. Sounds like a good idea. I will add this to my "take a closer look" TODO ;-) However, the next few days I will be packing my belongings (moving to England on Friday), so it will take a while before I have something for you to try out... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: accesskey attribute support
On Sat, Nov 16, 2002, Dave wrote: > The accesskey attribute takes a single character as a value. When > this character is pressed (IE and Mozilla require ALT + CHAR), the > browser will give focus to textbox, follow the link, check the box, > select the radio button, etc. Well, including the accesskey in the Plucker document should be quite easy (a new function code.) However, I can see two immediate problems, - how should the accesskey be entered on the Palm without interfering with the gesture actions? - only the accesskeys in the parsed content will be available (the viewer only parse the whole page the first time; to speed up the rendering it will only parse the visible paragraphs the next time you visit the page). That could probably be solved by "storing" the accesskeys in the meta database, though. Any suggestions on how to enter the accesskeys? /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: accesskey attribute support
On Wed, Nov 13, 2002, Dave Maddock wrote: > Has anyone considered supporting the accesskey attribute Well, I'm not sure I understand what you mean with "accesskey attribute." Can you please provide some more info and/or examples? /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Problem to build code from CVS (was: Thai Translation in Plucker 1.2)
On Fri, Nov 15, 2002, Andy Rabagliati wrote: > The problem appears to be around the viewer configure > script moving to the viewer directory. It could easily > be my mistake, but I tried quite hard. When you get the code directly from CVS you must run "autoreconf" to create the configure scripts and config.h.in (a source package would include these files.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Compressed/Uncompressed speed in viewer
On Wed, Nov 13, 2002, Bill Nalen wrote: > If I have plenty of room on my Palm, does it make sense to still > compress the pages? Yes, if you want to store more Plucker documents and still have room for other apps ;-) The compression is there to save space... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Default screen depth?
On Wed, Nov 13, 2002, Laurens M. Fridael wrote: > Why is it that the default screen depth is set lower than the device is > actually capable of? It is set to the default screen depth of the device since it runs best at that screen depth. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: problems with top-level Plucker configure.in
On Tue, Nov 12, 2002, Bill Janssen wrote: > What I mean to say is that it will attempt to configure and build > the viewer, but if that fails will not go on to configure the other > elements of the system which can still be usefully built. The viewer's configure script can't inform the top configure script that it has found errors. If it continued running it would either create an "empty" Makefile or no Makefile at all (which would break when running 'make') and I consider that to be a bigger problem than to make it "error out". At least that tells you right away that something is missing... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: another pluck-comics patch
On Mon, Nov 11, 2002, Dave Maddock wrote: > Attached is another patch for the pluck-comics tool. Thanks. I have included the changes in the main trunk. > BTW, should I continue to post my patches on the list or submit them > directly to someone? You can continue sending them to the list (or you could send them to [EMAIL PROTECTED]). Chris Hawks is the one that knows most about the pluck-comics script (he wrote it:), but since he can't access CVS sitting behind a firewall it wouldn't help to send the changes to him. However, he could probably provide feedback about the suggested changes. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: viewer/langs files
On Wed, Nov 13, 2002, masakazu wrote: > I think the source is provided mainly for developers :-) Sure, but the "problem" will still only occur if you are making (broken) changes to the resources, i.e. fix the problem instead of the symptom ;-) Anyway, adding the -f flag to ln or a "rm -f lang.h" before creating the symlink seems like a better solution than beginning to create subdirs for the language files. > OTOH, resources for plucker-desktop are distributed in ja/, en/, etc. You are comparing apples and oranges... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Swat!! Found another one.
On Tue, Nov 12, 2002, Chris Hawks wrote: > I didn't (mean to) say that the dimensions were negative. My mistake. I have fixed the problem in the main trunk. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: viewer/langs files
On Tue, Nov 12, 2002, Adam McDaniel wrote: > I disagree. It will also happen when there are problems accessing the > resource from the code directly. Well, I disagree with your disagreement ;-) The code we distribute will not run into this problem (under normal operration) or there is a bug that should be fixed. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Install ZLIB prc on a pre-OS3 device?
On Tue, Nov 12, 2002, Laurens M. Fridael wrote: > So it isn't installed at all? It's installed, but you can't use it. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Install ZLIB prc on a pre-OS3 device?
On Tue, Nov 12, 2002, Laurens M. Fridael wrote: > What happens when you install the ZLIB prc on a pre-OS3 device? Nothing. > I was thinking of bundling the Plucker Viewer with a future Windows > installer for JPluck. Any objections to redistributing the Viewer > this way? As long as it is distributed according to GPL no one will have any objections. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: toolbar question / hires images
On Tue, Nov 12, 2002, Adam McDaniel wrote: > My question though, does anyone have a problem in changing things to > be done in this way? I want to see how it works before I "cast my vote" ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: viewer/langs files
On Wed, Nov 13, 2002, matto wrote: > leaves lang.h when an error occurs in pilrc, and it must be deleted by > hand. The only time that will happen is when you are "hacking" the resource files, so it's a minor problem that only developers will run into. Anyway, if you don't want to remove it manually then just add a '-f' flag to "@$(LN_S) $(LANGDIR)/$*.h lang.h" (or remove the lang.h file before creating the symlink) and you will never have problems with lang.h being left behind again. > May I create sub directory in viewer/langs directory I prefer to have them in the same dir. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: problems with top-level Plucker configure.in
On Mon, Nov 11, 2002, Bill Janssen wrote: > the PalmOS viewer does not check to see if the environment permits > [it] to be built. Bollocks! If it didn't check the environment then why are you complaining that it "errors out"? > I don't want to fiddle with that till he's done. I thought I'd just > change the default to disable, so that one would have to configure > with --enable-palmosbuild to enable it. You will not "fiddle" with it at all until you know what you are doing. In case you have missed it, the viewer has its own configure script and there is nothing to "disable" in that script. However, I don't agree with you that everything should be disabled by default. If I download a source package I usually intend to build the program not just sit and admire the code. Everything should be enabled by default and then it's up to the developers to make sure that they have the correct environment (or disable the parts they can't build.) BTW, I must say I'm a bit confused by your "reply technique"; sometimes proper replies, next time top posting, and then all of sudden replies with no context at all... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: problems with top-level Plucker configure.in
On Mon, Nov 11, 2002, David A. Desrosiers wrote: > Fatal errors without graceful checking are just ugly, and can lead > to more bug reports than we probably care to see. I resent the allegation that the viewer's configure script doesn't do any "graceful checking"; it checks for two different build environments (prc-tools 0.6.0beta and prc-tools 2.x), the use of different SDKs, ZLib source package, etc. Neither are errors reported by the viewer's configure script "fatal"; creating an "empty" Makefile would be the cause of more bug reports than any error report from a configure script. If a user doesn't tell the top configure script that the viewer shouldn't be built then the configuration will "halt" if the tools to build the viewer aren't available; the viewer's configure script can't tell the top configure script that the viewer can't be built. If the user still attempts to run 'make' after the "failed" configuration, he better not complain about 'make' failing because he will only make a fool of himself... > Using long arcane (easy to misspell) options probably aren't the > best choice for usability. And that's why the default is to build everything, i.e. you only have to check the name of the options when you want to turn something off (or change some feature.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Swat!! Found another one.
On Sun, Nov 10, 2002, Chris Hawks wrote: > it should be: > reqMem = (UInt32) imageWidth * (UInt32) imageHeight * (UInt32) pixelDepth; Yep, that's the way it was done in 1.2, but I missed to include that when changing the code to use the BmpGlue functions. It's not necessary for the pixelDepth, though (it's already unsigned.) I don't understand how the dimensions could be negative, though. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Data record order
On Tue, Nov 12, 2002, Tim Wentford wrote: > Does this imply that the records are guaranteed to be stored in record id > order so that I can do the same in the Zaurus reader The PalmOS viewer wouldn't work unless they were stored in order. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: problems with top-level Plucker configure.in
On Mon, Nov 11, 2002, Bill Janssen wrote: > why would we want a configuration script that errors out, instead > of completing? If you say that you want to build the viewer and you don't have the tools to build it then I don't consider it to be a problem when it "errors out." /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Data record order
On Sun, Nov 10, 2002, Laurens M. Fridael wrote: > Does the order of the data records in the document affect display > performance? Not that much. The viewer uses a binary search (a O(log n) algorithm) to find the correct record, so it will not access that many records in the Plucker document to find the correct one. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: problems with top-level Plucker configure.in
On Sat, Nov 09, 2002, Bill Janssen wrote: > In particular, this is true for the PalmOS viewer If the configure phase "fails" when tools are missing how can there be a Makefile for the viewer? > In addition, the sub-directory configure for the PalmOS viewer fails What part "fails"? If it aborts the process because tools are missing then that is the intended behaviour and it will not change. > during the configuration process, aborting the configuration even > though there are other useful subdirectories which *can* be built. If you don't have the tools to build the viewer then use the --disable-palmosbuild option... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Links to multi-images (was: Quickie)
On Tue, Oct 29, 2002, Chris Hawks wrote: > the next multiImage is appended to the 'anchor' for the previous > image... So all images when tapped display the follow link/show > image popup even tho they have no link. Nice catch. I did know there was a problem somewhere in the anchor handling, since tapping on "normal" links would sometimes display the follow link/show image popup and it was one of the problems in my TODO list. Hopefully, that problem has been fixed, too (so I can remove that item from my TODO list -- it's long enough:) > DoAnchorBegin( pContext, tContext, functionWidth ); > DrawInlineImage( inlinedImage, tContext, functionWidth ); > AnchorStopImage( tContext, pContext->fontHeight, *functionWidth ); > -AnchorStop( tContext, pContext->fontHeight ); > +DoAnchorEnd( pContext, tContext, functionWidth ); I would suggest that we change DoAnchorBegin to AnchorStart and keep the AnchorStop. We have all necessary data to call AnchorStart directly instead of first calling DoAnchorBegin and let it call AnchorStart (same thing applies for DoAnchorEnd/AnchorStop.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Image support (was: Tables Conversion)
On Wed, Oct 30, 2002, Chris Hawks wrote: > It doesn't do images. But, neither did we in version 0.3. Actually, version 0.03 of Plucker was the first version with image support ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Add new tag in *.rcp
On Fri, Nov 08, 2002, matto wrote: > Thanks. I modified and moved the rcplint.pl to scripts dir, and made > some changes to viewer/Makefile. Well, you did *everything* that was necessary to turn the Makefile into a Makefile.in file ;-) However, I made a minor change to the distclean target, so that it runs the clean target and also removes the Makefile. I have thought about creating some kind of script that could be used to make sure that all resources are included in the rcp files (there are too many resources to continue checking them manually:) and your script is much better than what I had planned to write ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: dev tools
On Fri, Nov 08, 2002, David A. Desrosiers wrote: > Unfortunately, until CW is either available on our platform Even if CW was available on Linux it doesn't necessarily mean I would use it ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: dev tools
On Fri, Nov 08, 2002, Arthur Roolfs wrote: > That being the case, I assume that everybody is using POSE for > debugging and stepping through code with prc-tools POSE and sometimes my Palm V when I need to test something running on a real device; DDD + gdb works just fine for me. > Being able to do the latter is really the only reason to consider CW. No one stops you from using CW; if you find something in the code that doesn't work with CW then send us a patch and we will take a closer look at it and see if it can be integrated without breaking it for prc-tools users. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Add new tag in *.rcp
On Fri, Nov 08, 2002, David A. Desrosiers wrote: > automake, of course. Welcome to my hell. No, we don't need anything that complex. I will create a Makefile.in either later tonight or this weekend and send to Matto so he can take a look; it's not complicated ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Copying text within Plucker Browser
On Fri, Nov 01, 2002, Dalibor Raduch wrote: > have you ever thought about a copying option. There is a copy-to-memo feature in the unstable branch. Will take a while before it turns up in a stable version, though. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: dev tools
On Mon, Nov 04, 2002, Adam McDaniel wrote: > I've heard that it is possible to use Codewarrior I've made some changes to the code earlier this year (after suggestions from Florent Pillet) that should make it possible to build it also using CW. However, it's not really "supported" and it may break, since we don't use CW and may (by mistake) use some GCC-only features ;-) > Atleast with prc-tools people here can help you out :) It's also the only environment that I will "officially" support. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Add new tag in *.rcp
On Tue, Nov 05, 2002, masakazu wrote: > I make a small hand-made tool to compare sample.rcp with any lang.rcp > in viewer/langs directory. Great work, but maybe we could change the Makefile to be a Makefile.in? Makes it consistent with the other config files. Also, it would probably be a good idea to put the lint script in the scripts dir and include a 'test' target in the viewer's Makefile that will run the script and report the results. If the script didn't create any output when there are nothing to report it would be possible to just check for *.lint files to find out if there are some problems. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: VFS oddity, HandEra silkscreen bug
On Fri, Oct 25, 2002, Eric J Schwertfeger wrote: > How do you go about setting the label on a SD/CF card from the > HandEra? VFSVolumeSetLabel, i.e. the viewer will provide you with a dialog making it possible for you to set a label. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Observations during install of plucker_bin-1.2.tar.gz
On Thu, Oct 24, 2002, Larry W. Virden wrote: > Do you want to run plucker-setup now? [y] [snip] > Alas, now I have to go through all of this AGAIN You only had to re-run plucker-setup. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Thai Translation in Plucker 1.2
On Wed, Oct 23, 2002, Karin Pimsamsee wrote: > And that feeling huge enough to push me make a Thai translation of > Plucker. Thanks, I will add it to the 1.2 branch (i.e. it will be included in the next stable release) and to the main trunk (i.e. the unstable "branch"); it can be updated when you have tested the version Andy sent. Also, it is not that hard to fix the soft-hyphen (0xAD) problem you have reported (and others have mentioned the same problem on this list for both Chinese and Japanese devices.) The remaining question is whether it is possible for the viewer to detect this "conflict" automatically or if we should add an option to turn it on/off (and whether such an option should be set at compile time or run time.) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: VFS oddity, HandEra silkscreen bug
On Wed, Oct 23, 2002, Eric J Schwertfeger wrote: > If you happen to have more than one memory card in the handheld, Plucker > will list databases on all cards, but trying to pull them up results > in "Cannot find document in RAM or on external card" except for one card. The only thing I can say without a closer look is that it has worked with both cards. I created a (very alpha) Handera version a long time ago and it could access both cards. One thing that doesn't work and might give the problem you describe is when both cards have the same volume label (i.e. if neither have been given a label you will run into this problem) I have promised to provide a fix for this, but it's not at the top of my priority list, yet. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Marketing strategy (was: OT -- Keeping the Plucker Logo)
On Mon, Oct 21, 2002, Alexandre Enkerli wrote: > But on the topic of corporate-appeal, is there a "marketing" strategy > for Plucker? We are "hackers" not suits, so do you want an extra guess whether we have a "marketing strategy" or not? ;-) > Not only can it compete with AvantGo on the Palm As I said already back in '99, I'm not working on Plucker to gain market share, if we have a good product and it is useful to other users, too, then I'm a happy camper... It has never been my goal to compete with AvantGo or any other product for that matter. I just want to create a good offline HTML reader (and e-book reader). Actually, one reason I haven't spent any time on adding DOC support to Plucker is that there are good (and free) DOC readers, CSpotRun and Weasel (I even contributed code to Weasel this year:) Of course, if someone else implements DOC support in Plucker it won't be turned down ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Plucker usage
On Tue, Oct 22, 2002, Rick Wootten wrote: > 1. What do we need to do to be listed as a Plucker site in your > documentation? Provide a web site designed for PDAs would be a good start ;-) > 2. What is the possibility of working more closely with you to understand > the features being developed so we can take full advantage of them? Pretty good, i.e. all Plucker developers and contributors are active on this list. And there is a *lot* of activity ;-) So go ahead; ask questions, provide feedback, discuss new features, ... > 3. We have discovered some issues "plucking" our site and wondered where the > best place is to direct these questions. The mailing list? A forum? Mailing list is OK or file a bug report at http://bugs.plkr.org . /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Hardcopy and Bookmark feature
On Wed, Oct 23, 2002, masakazu wrote: > I added the hardcopy and bookmark template feature is added to the main > trunk Great, I will take a look. > I am surprised to see the newest code because I have been dealing with > much older branches... Well, some of my code has been completely local (and is still kind of "unstable":) > > BTW why don't you merge many similar label list for action menus such > as gestures, tap, button assignment, and toolbar? It's a matter of having time to do it, i.e. things that do work are left alone as long as there are other more important things to do ;-) Feel free to do something about it, though. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: About the pacifier
On Tue, Oct 22, 2002, Mark Lillywhite wrote: > I do remember I was sitting in the living room of my apartment in > Maitland St, Toronto The default home.html file in Plucker still has a reference to Toronto, i.e. it includes a link to the weather forecast for Toronto ;-) > Also fwiw, the original name of the "plucker" software was "flight > attendant". That name was used in the home.html file for the very first release of Plucker. It disappeared in the 0.02 release, though. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: French translation in 1.2
On Tue, Oct 22, 2002, Nicolas Huillard wrote: > There was a merge problem when Mike merged the 1_2 branch to the main > trunk, Hmm, that merge was done almost a month ago (and I'm sorry if I broke something) ;-) revision 1.34 date: 2002/10/18 11:46:13; author: nhuillard; state: Exp; lines: +31 -32 Several updates. Some were lost as of '1.33 2002/09/26 15:27:11 nordstrom' ? revision 1.33 date: 2002/09/26 15:27:11; author: nordstrom; state: Exp; lines: +42 -26 Merged with release branch BTW, yesterday, when I merged several branches (some local ones, too) I made sure to not change any existing strings in fr.rcp (I did add a few new strings, though.) > These changes could be included in some 1.2.1 release if there is one (not > so urgent, but I wouldn't like the errors to spread around the world for > months). Well, if there are errors in 1.2 (and the fr.rcp file in the 1.2 branch is different from the one in the main trunk) then you shouldn't blame me for them; I haven't touched the French translation in the 1.2 branch since you checked in a new version Oct 3 ;-) revision 1.28.2.9 date: 2002/10/03 15:26:48; author: nhuillard; state: Exp; lines: +4 -5 Finished translating "$$PREFS: HELP" I thought that *was* the translation intended for the 1.2 release... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: branches in i18n branch
On Tue, Oct 22, 2002, masakazu wrote: > I'm very sorry to quote private communication with micke to mailing > list. It's OK; it wasn't that "private" anyway ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: branches in i18n branch
On Tue, Oct 22, 2002, masakazu wrote: > Here is an implementation of hardcopy and bookmark feature. > (Patch for plucker_1_2) You might want to commit the changes to the code in the main trunk (i.e. the unstable branch.) > Almost all changes are made in paragraph.c, where many functions are > added. Shall I separate them into another file? That can wait until we have a more stable version of the development code. > BTW, may I add "Delete Document" feature in buttons/gestures/tap action > menu? Sure, but only in the main trunk. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Hires version is still in development (was: *Sniff*)
On Tue, Oct 22, 2002, Robert O'Connor wrote: > A new Windows package was waiting on Adam's hires version, which > would then package the final 1.2 hires, Please don't call it 1.2 (it's not included in 1.2; it's still development code.) Any attempts to jump between the released 1.2 version and the hires version will break, so it's not a good idea to give the impression that they are more or less the same... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Plucker Logo (Was Re: New Web Site)
On Mon, Oct 21, 2002, Robert O'Connor wrote: > The pacifier does raise a few questionmarks in corporate > deployments Well, if anyone wants to deploy Plucker in a corporate environment then I guess they will be competent enough to change the icon if they find it "questionable" ;-) I have another Free Software program on my device called Strip (a program I also have contributed, too) that is used to store passwords and pin codes. I guess some users will be offended/embarrassed over that name, but it is just a name... > Some like the pacifier though. Well, as long as I maintain the viewer it will use the 'pacifier' icon ;-) > Some even like the chicken (which I guess has a stronger connection > to 'plucking' since you can plucker feathers, but even that took me > a few months to tie together). To me the chicken is more related to Mark's company name, Rubberchicken, than to the name of the app (although Plucker and chickens are quite related, too:) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: New Web Site
On Fri, Oct 18, 2002, Edward Rayl wrote: > I tend to think it looks like a pacifier myself (maybe you have to > be a parent). Doesn't look link a chicken, so what is it? :-) It's a pacifier; you will have to ask Mark *why* a pacifier is used for the application icon, though ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: documentation on the Web site?
On Fri, Oct 18, 2002, Bill Janssen wrote: > Right now it takes one to the HTML version of the user manual, which > is buggy and out-of-date. The Viewer chapter is up-to-date ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Accept the license or don't *use* Plucker? (was: owner_id_build vs.copyprevention_bit)
On Thu, Oct 10, 2002, Robert O'Connor wrote: > User has to select the 'I accept' radio button on the license screen, > if they want to continue with rest of install. If don't like the GPL, > then they can choose not to install. One problem with that "license agreement" is that you don't have to accept GPL to *use* the program. The license only applies when you want to distribute the program (or a modified version.) And we don't really have to *ask* anyone to accept the license; if they don't accept the license they are not allowed to copy, modify, and/or distribute the program. GPL grants you rights, unlike "normal" EULAs that takes away rights (and a lot of the crap included in the EULAs are probably not even legal:) I still think it is a good idea to display the license to the user, but I have my doubts about the accept/decline options ;-) Just some food for thought. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: plucker-build man page updated
On Wed, Oct 16, 2002, Pierre Phaneuf wrote: > By the way, I find it pretty weird that Plucker has a tool to go from a > PDB to the cache files (plucker-dump), but not the other way around. If you check the conduit dir (in CVS) there is a tool called sync.pl. It can be used to create a Plucker document from the files in the cache dir. It's described in the documentation (chapter 5.) > Also, is plucker-decode supposed to do anything other than crash? Yes, but it seems that recent changes to the parser broke some parts. Anyway, if I remove the "[0]" on line 1375 in PluckerDocs.py (btw, the version in CVS is 1.43) it seems to work again. However, Bill knows more about the parser than I do, so I leave it up to him to make any permanent changes ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: help for making a ColdSync conduit
On Tue, Oct 15, 2002, Pierre Phaneuf wrote: > Wouldn't it make more (or as much) sense to invalidate the cached data > when the modified date changes too? Well, the modified date changes when you rename the document, or move it from/to an external card, too. I don't want to lose the cached data for those kind of "changes". I guess it is a matter of defining what should be considered to be a "modified" document instead of a "new" document, i.e. how much can you "modify" before it is a new document ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: plucker-build man page updated
On Wed, Oct 16, 2002, Pierre Phaneuf wrote: > Whoa! Don't remove that feature just yet! I never said we should remove it; I only tried to provide some background for that option, since Bill had some "doubts" about it in the man page ;-) Anyway, you have just provided one reason for the '-c' option to be included in plucker-build ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: 1.2 beta 13 Document Library bug w/clean install
On Wed, Oct 16, 2002, David A. Desrosiers wrote: > and will only affect first-time users who install documents in > Plucker and get thrown into the Document Library, Nope, it will never affect "first-time users", since the default is to sync the document list automatically. > but I'm curious what causes it.. Well, I guess it's necessary to redraw the whole table (after setting the column widths) when manually updating the list. Another related "layout" issue can be seen if you set the scrollbar to Left and either don't have any documents installed or select a category setting that won't include any documents in the list. > and whether that cause could be lurking over the top of another > potentially larger bug underneath? Don't worry; I wouldn't ignore this problem if it wasn't for the fact that it's just a minor layout issue and (much more important) that it will be history as soon as we start using the new document library... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: plucker-build man page updated
On Tue, Oct 15, 2002, Bill Janssen wrote: > I've updated the plucker-build man page to cover configuration file > parameters. Alternatively, specifying the option --update-cache will update a cache of Plucker records (though it's not clear what this is good for). I don't know if it's used for anything today, but a long time ago we didn't have the tools to create a Plucker document directly. Instead we used lynx and awk scripts to download and convert web pages into "records" that were stored in the cache dir. When we had finished the gathering of web pages we used a C program to "send" each record to the Palm device and create the Plucker document on the device. To summarize, I guess it is included for historical reasons ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: 1.2 beta 13 Document Library bug w/clean install
On Wed, Oct 16, 2002, David A. Desrosiers wrote: > Any small thing to refresh the screen will fix it. It's not major, > but I'm curious why it happens like that. It's not like the titles are > obscured, just pushed over to the right. Well, I think I know why it happens, but I will not do anything about it. When we start to use the document library from the hires branch this will not be an issue any longer... /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
