Re: Compiler-chain issues(?) with DIA code from cvs
At 09:36 AM 5/6/2004, you wrote: Thanks for the note. I've upgraded pilrc to 3.2b1 -- it generates a viewer.rcp.s file identical to pilrc 3.0 though... I didn't think to do a cmp with the .ro files (if that would even be meaningful). What is the viewer.rcp.s file? I don't see how PilRC can actually generate assembly code, which is the traditional meaning of .s. I just looked at the Makefile for Plucker, and I'm still not seeing how a .s file comes into play. The changes to PilRC would alter the .ro files, since those are the files that actually contain all of your resources. -- Ben Combee, DTS technical lead, PalmSource, Inc. Read Combee on Palm OS at http://palmos.combee.net/ ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Compiler-chain issues(?) with DIA code from cvs
From: Ben Combee [EMAIL PROTECTED] What is the viewer.rcp.s file? It's produced by a combination of cpp and my doaddition.pl script that does addition within wordlist resources. Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Compiler-chain issues(?) with DIA code from cvs
On Tue, 04 May 2004, Ben Combee wrote: You really should be using pilrc 3.1 or 3.2 beta -- the 3.0 version has problems with auto control sizing and also doesn't set some control attributes correctly. Well, I finally got back to a machine I could sync to and tried a new version compiled (in conjunction with) pilrc 3.2b1 and I see exactly the same behavior... Can someone comment on what version of prc-tools they are using? I have 2.2.90 -- the most current version for Debian's 'sid' distribution. However, I see that it is fairly dated (Mar 2003). Should I be upgrading to 2.3 off the sourceforge.org site? -- Brad -- Brad Sawatzky [EMAIL PROTECTED] University of Virginia Physics Department Ph: (434) 924-6580Fax: (434) 924-7909 ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Compiler-chain issues(?) with DIA code from cvs
The PDA is a Garmin iQue 3600, a PalmOS 5.2.1 device, 320x480 screen. I get a consistent crash (requires pin-reset) under the following conditions: - completely fresh install on the PDA (all prefs, etc deleted using FileZ) - plucker viewer 1.7.1 (current from today's cvs) - compiled under linux (debian sid) using prc-tools 2.2.90 pilrc 3.0 ./configure --enable-armlets The error occurs when switching to the mainform (the form that displays the actual document text, etc), but only if the toolbar is being drawn. The crash occurs immediately after drawing the toolbar but before any page text is drawn. If the toolbar is disabled in the prefs (ie. while on the library form) then the mainform will render successfully. There still seems to be a leak though(?), as toggling the DIA a few times will soon lead to crash. FWIW, the error dialog reads: MemoryMgr.c (line 3635) Null handle The only compile-time warnings are of the form: viewer.rcp:17020: warning : Form has editable field(s) without Graffiti State Indicator viewer.rcp:17228: warning : Form has editable field(s) without Graffiti State Indicator viewer.rcp:17445: warning : Form has editable field(s) without Graffiti State Indicator The daily snapshot works fine. Earlier versions of of the plucker code (prior to the introduction of the DIA code) compile and run cleanly. Can someone tell me what prc-tools and pilrc versions are being used to compile the snapshots? I have a hunch that pilrc 3.0 is doing something unfortunate. Unrelated (AFAIK) compile-time quirk: - A 'make' from either the plucker-cvs/ or viewer/ directories fails when it enters plucker-cvs/viewer/fonts. (cd plucker-cvs/viewer/fonts; make) compiles cleanly. The problem is that the root makefile attempts to compile fontconf.c using m68k-palmos-gcc rather than just gcc... Any thoughts? -- Brad -- Brad Sawatzky [EMAIL PROTECTED] University of Virginia Physics Department Ph: (434) 924-6580Fax: (434) 924-7909 ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Compiler-chain issues(?) with DIA code from cvs
On Tue, 4 May 2004, Brad Sawatzky wrote: I get a consistent crash (requires pin-reset) under the following conditions: - completely fresh install on the PDA (all prefs, etc deleted using FileZ) - plucker viewer 1.7.1 (current from today's cvs) - compiled under linux (debian sid) using prc-tools 2.2.90 pilrc 3.0 ./configure --enable-armlets The error occurs when switching to the mainform (the form that displays the actual document text, etc), but only if the toolbar is being drawn. The crash occurs immediately after drawing the toolbar but before any page text is drawn. If the toolbar is disabled in the prefs (ie. while on the library form) then the mainform will render successfully. There still seems to be a leak though(?), as toggling the DIA a few times will soon lead to crash. Send me a copy of your viewer.rcp.s file. Alex -- Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED] Philosophy Department || online papers and home page: Georgetown University || www.georgetown.edu/faculty/ap85 Washington, DC 20057|| U.S.A. || - Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
RE: general DIA support code
There is an advantage to storing the resize data in resources rather than in an array, namely that one can then distribute alternate skins that include not only new form layouts but also new ways for forms to resize, and moreover it's easier for endusers to the stuff in a separate resources. And, of course, it's nice to have a free solution, under a license compatible both with commercial and GPL stuff. :-) Alex -- Dr. Alexander R. Pruss Department of Philosophy Georgetown University Washington, DC 20057-1133 U.S.A. e-mail: [EMAIL PROTECTED] online papers and home page: www.georgetown.edu/faculty/ap85 -- Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
RE: general DIA support code
Sent to wrong list. Sorry. -- Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED] Philosophy Department || online papers and home page: Georgetown University || www.georgetown.edu/faculty/ap85 Washington, DC 20057|| U.S.A. || - Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
The compile problems are fixed. Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
---Reply to mail from Alexander R. Pruss about DIA code committed The compile problems are fixed. Whatta guy! Thanks! ---End reply Christopher R. Hawks HAWKSoft - Let's call it an accidental feature. -- Larry Wall ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
DIA code committed
I've committed the DIA code. This has consequences for all developers who modify or create forms. Many forms now come with resize descriptions in viewer.rcp.in. If you modify a form, you need to make sure that the resize description for the form is also modified. Things will crash, for instance, if the resize description mentions an object that the form does not contain, and, conversely, objects not mentioned in the resize description will not move or change size on DIA resize. Any new forms need to have event handlers that call the appropriate ResizeHandle*() functions, even if the forms do not actually resize. You should read DIA.txt for information on how all this works. I would like to strongly request that people not make new forms for different sizes, the way the old code had separate Sony silk min, Sony wide, etc., forms. Everything should be handled via the resize info. The resize descriptions are flexible enough to allow one to handle fairly complex forms. If you need more, you can of course put in a hook in the winDisplayChangedEvent handler for the form. (Note that the way my DIA support code works, winDisplayChangedEvent is now posted to forms under ALL supported platforms that have resizable DIA, including Handera and Sony.) I haven't included resize info for ALL forms. Those that don't have resize info have behavior that defaults to the PalmOS 5.2+ default of maximizing DIA and disabling resize. This is handy for things like the search form. But at the same time, people may want to add explicit resize info for some other forms for which I have not added it. This may involve creating new bins, a concept explained in DIA.txt. A bin is a collection of forms which have the same DIA state, so that if the user changes the DIA state in one form in a bin, it gets changed in all the forms in the bin as well. For instance, it makes sense that all forms that may require user to type things in (e.g., the keyboard remap form and the search form and the email form) to share a bin. It also makes sense that all forms where more space is useful and where graffiti entry is less critical should share a bin. For instance, the search result form and the mainform should share a bin. The DIA settings for each bin are saved in the prefs database. Currently, there are only two bins, a mainform and a library bin, both of which default to DIA minimized. One improvement over the previous version is that the two can have different default states if the user wants. This is handy since the library form lets you enter the first letters via graffiti, and so you might want DIA maximized for it, while almost everybody would like DIA minimized in the mainform. Getting the DIA behavior consistent across all forms by producing resize info where appropriate is something that I would like people to help me with. Finally, any bug fixes to resize*.[ch] and DIA.[ch] should also be sent to me in addition to being put in CVS because the code is being used by PalmBible+ as well, and I want to maintain a two-way flow of bug fixes. Alex -- Dr. Alexander R. Pruss Department of Philosophy Georgetown University Washington, DC 20057-1133 U.S.A. e-mail: [EMAIL PROTECTED] online papers and home page: www.georgetown.edu/faculty/ap85 - Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
Getting the DIA behavior consistent across all forms by producing resize info where appropriate is something that I would like people to help me with. One slightly-off-topic question... should we continue to call this DIA in our codebase, when it is a new, homegrown reimplementation of the resize portions of DIA? Are there any trademark issues with using that name in the project? d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
From: David A. Desrosiers [EMAIL PROTECTED] Getting the DIA behavior consistent across all forms by producing resize info where appropriate is something that I would like people to help me with. One slightly-off-topic question... should we continue to call this DIA in our codebase, when it is a new, homegrown reimplementation of the resize portions of DIA? Are there any trademark issues with using that name in the project? I am using DIA as the generic term for what Palm now calls DIA and what Sony and Handera called virtual silkscreen and silkscreen, respectively. I don't THINK there are any trademarks here, but if there are, then we can change DIA to Silk everywhere except in the Palm API calls. Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
I just grabbed the 12:06 build from today, and while not 100%, is a major step forward for compatability with my T3. The Library form could use support for the longer/wider page size. But actually viewing a pluck looks perfect. I also noticed that the code gets confused with the full image page you get when you click on a resized image that a full/larger image exists for (and can be scrolled). It seems the form that pops up goes back to the 320x320 size (DIA shown), but still thinks it has the full screen. So depending on the rotation, it cuts off on the right or the bottom. It also moves the exit/scroll box under the silk (when in portrat). Lucky my T3 lets me exit the form with the center button of the 5way. Those are the only two issues I can pull out immediately. Thanks so much for adding this support. --Wes Alexander R. Pruss wrote: I've committed the DIA code. This has consequences for all developers who modify or create forms. Many forms now come with resize descriptions in viewer.rcp.in. If you modify a form, you need to make sure that the resize description for the form is also modified. Things will crash, for instance, if the resize description mentions an object that the form does not contain, and, conversely, objects not mentioned in the resize description will not move or change size on DIA resize. Any new forms need to have event handlers that call the appropriate ResizeHandle*() functions, even if the forms do not actually resize. You should read DIA.txt for information on how all this works. I would like to strongly request that people not make new forms for different sizes, the way the old code had separate Sony silk min, Sony wide, etc., forms. Everything should be handled via the resize info. The resize descriptions are flexible enough to allow one to handle fairly complex forms. If you need more, you can of course put in a hook in the winDisplayChangedEvent handler for the form. (Note that the way my DIA support code works, winDisplayChangedEvent is now posted to forms under ALL supported platforms that have resizable DIA, including Handera and Sony.) I haven't included resize info for ALL forms. Those that don't have resize info have behavior that defaults to the PalmOS 5.2+ default of maximizing DIA and disabling resize. This is handy for things like the search form. But at the same time, people may want to add explicit resize info for some other forms for which I have not added it. This may involve creating new bins, a concept explained in DIA.txt. A bin is a collection of forms which have the same DIA state, so that if the user changes the DIA state in one form in a bin, it gets changed in all the forms in the bin as well. For instance, it makes sense that all forms that may require user to type things in (e.g., the keyboard remap form and the search form and the email form) to share a bin. It also makes sense that all forms where more space is useful and where graffiti entry is less critical should share a bin. For instance, the search result form and the mainform should share a bin. The DIA settings for each bin are saved in the prefs database. Currently, there are only two bins, a mainform and a library bin, both of which default to DIA minimized. One improvement over the previous version is that the two can have different default states if the user wants. This is handy since the library form lets you enter the first letters via graffiti, and so you might want DIA maximized for it, while almost everybody would like DIA minimized in the mainform. Getting the DIA behavior consistent across all forms by producing resize info where appropriate is something that I would like people to help me with. Finally, any bug fixes to resize*.[ch] and DIA.[ch] should also be sent to me in addition to being put in CVS because the code is being used by PalmBible+ as well, and I want to maintain a two-way flow of bug fixes. Alex -- Dr. Alexander R. Pruss Department of Philosophy Georgetown University Washington, DC 20057-1133 U.S.A. e-mail: [EMAIL PROTECTED] online papers and home page: www.georgetown.edu/faculty/ap85 - Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
From: Wmason [EMAIL PROTECTED] I just grabbed the 12:06 build from today, and while not 100%, is a major step forward for compatability with my T3. The Library form could use support for the longer/wider page size. This problem is due to something really strange that I can't figure out. If you remove the FrmDrawForm() call from LibraryFormInit(), it works (but of course buttons don't get drawn). Strangely enough, with DIA minimized, calling FrmDrawForm() in the library form (not in other forms, it looks like) causes DIA to get maximized. Any ideas? Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
Hi, Great to see that DIA is now implemented! I was working on a patched solution for it, but now that there is a clean solution, I'm happy. Some points, though: 1) About the problem with the Library form... I had the same problem in my own solution; I fixed it by calling: PINSetInputAreaState( pinInputAreaUser ); Don't know why this actually happens, but this fixed my problem... 2) Rotating the screen using DIA (480x320) makes the scrolling very slow (I personally use Control: Mode 3 in preferences). Instead, using the rotation option provided in the Font form is much more faster... It would be nice to handle DIA rotation the same way as the rotation option... 3) The snapshot source version (17h and 18h) seems to not compile when --disable-palm-dia is passed to configure. 4) The snapshot source version (17h and 18h) makes my Palm crash at startup time, with a MemoryMgr, line something message. Haven't look deeply at this, since the precompiled viewer version works fine. Guess I missed some fact about the compilation... Still, I could not test the fix in (1) because of this :( Any idea ? James smime.p7s Description: S/MIME cryptographic signature
Re: DIA code committed
Too fast ;) I'll grab tomorrow's build as I don't have a compile environment setup. Thanks! --Wes Alexander R. Pruss wrote: I just grabbed the 12:06 build from today, and while not 100%, is a major step forward for compatability with my T3. The Library form could use support for the longer/wider page size Fixed. Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
Fullscreenform works now. ARP ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed
---Reply to mail from James Watkins-Harvey about DIA code committed 3) The snapshot source version (17h and 18h) seems to not compile when --disable-palm-dia is passed to configure. No, it doesn't. The problems are (mostly) with the #defines in resize.h SaveResizePrefs() takes 3 parameters, but, the #define only has 2. ResizeHandleFrmXXX() are #defined as true, but, the value is not used so gcc complains. And ResizeHandleWinEnterEvent() is called in mainform.c and the return value (or #define) is not used, so gcc complains some more. The attached patch 'fixes' the problems, but, the one in mainform.c may be better handled. (Do the forceMainFormUpdate check first and then set handled to ResizeHandleWinEnterEvent() or true. ---End reply Christopher R. Hawks HAWKSoft - Windows is the answer, but only if the question was 'what is the intellectual equivalent of being a galley slave?' -- Larry Smith, in comp.os.linux.misc dia.diff Description: File attachment
Re: DIA code committed (StringMgr.c: Null string passed errors)
Ok, all liked fine until I rotate the screen in the library form from portrait to landscape and then back to portrait with the DIA/Silk minimized. I got: StringMgr.c, Lin:72, NULL string passed And for once the Reset button worked. I then tried to reproduce the error. I rotate with the silk visible, and it was fine. I rotated again with the silk hidden and it was fine. Daunted, I made the silk visible and entered a document, and exited (same state it was in the first time it errored). I then loaded Plucker again, clicked on the folder icon to get the library form, hid the silk, rotate the screen (using the dia controls). First from portriat to landscape and then to portriat. Same Error. (Screen is blank) After I reset it again, I played some more. Started it with the library form active and rotate it with the silk visible, When back to portrait, hid the silk, same error. (screen is drawn) I hope these help. I'll look for any other possible bugs. --Wes Alexander R. Pruss wrote: From: Wmason [EMAIL PROTECTED] Too fast ;) I'll grab tomorrow's build as I don't have a compile environment setup. The builds are hourly. :-) Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed (StringMgr.c: Null string passed errors)
On Sun, 18 Apr 2004, Wmason wrote: I then tried to reproduce the error. I rotate with the silk visible, and it was fine. I rotated again with the silk hidden and it was fine. Daunted, I made the silk visible and entered a document, and exited (same state it was in the first time it errored). I then loaded Plucker again, clicked on the folder icon to get the library form, hid the silk, rotate the screen (using the dia controls). First from portriat to landscape and then to portriat. Same Error. (Screen is blank) After I reset it again, I played some more. Started it with the library form active and rotate it with the silk visible, When back to portrait, hid the silk, same error. (screen is drawn) I can't duplicate this in the T3 simulator. How many entries do you have in your library? Which columns are showing? Etc. If you could duplicate this in the simulator and send me a snapshot (but don't send it to me without warning me first--I need to check if I have space in this email account to receive it) that would really help. THere isn't some problem with the form title during the rotation is there, by any chance? Alex -- Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED] Philosophy Department || online papers and home page: Georgetown University || www.georgetown.edu/faculty/ap85 Washington, DC 20057|| U.S.A. || - Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA code committed (StringMgr.c: Null string passed errors)
Ok, I'll hunt down the simulator. I should have access to it. As for number of items in my list, 147 (146 on card in /PALM/Programs/Plucker [totaling abour 59.7mb], one in memory [PluckerUserGuide, 139k]). As for sending it to you, I'll post it to my site and just give you a link to it. The form title in one instance turned into a box, in another instance, it gave the error. This may be part if not all of it. --Wes (unofficial T3 Tester) Alexander R. Pruss wrote: On Sun, 18 Apr 2004, Wmason wrote: I then tried to reproduce the error. I rotate with the silk visible, and it was fine. I rotated again with the silk hidden and it was fine. Daunted, I made the silk visible and entered a document, and exited (same state it was in the first time it errored). I then loaded Plucker again, clicked on the folder icon to get the library form, hid the silk, rotate the screen (using the dia controls). First from portriat to landscape and then to portriat. Same Error. (Screen is blank) After I reset it again, I played some more. Started it with the library form active and rotate it with the silk visible, When back to portrait, hid the silk, same error. (screen is drawn) I can't duplicate this in the T3 simulator. How many entries do you have in your library? Which columns are showing? Etc. If you could duplicate this in the simulator and send me a snapshot (but don't send it to me without warning me first--I need to check if I have space in this email account to receive it) that would really help. THere isn't some problem with the form title during the rotation is there, by any chance? Alex -- Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED] Philosophy Department || online papers and home page: Georgetown University || www.georgetown.edu/faculty/ap85 Washington, DC 20057|| U.S.A. || - Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur. - Paul of Worczyn (1424) ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
DIA support
Well, I've got full DIA support in PalmBible+. Now it's time to do it in Plucker. Given that people have been asking for Palm DIA support for half a year, any chance the support could make it into HEAD despite the feature freeze? The amount of changes to the code will actually be pretty small. I include below information from PalmBible+'s DIA.txt on what needs changing. Basically, it just means that each form has to call some special handlers, and then we need to add a bunch of new resources to the viewer.rcp.in file. The main change to existing Plucker code is that all the current silkscreen code would disappear and be replaced by PalmBible+'s resize.c and DIA.c (available in cvs: the project page is www.sf.net/projects/palmbibleplus), and the alternate size forms from viewer.rcp.in will be removed. The code appears to work very nicely in sim and POSE for both vertical and horizontal resizing, even with fairly complex forms (e.g., ones with two side-by-side lists which need to resize equally). 1. To support Sony, compile DIA.c with -DSUPPORT_DIA_SONY. To support Handera, compile DIA.c with -DSUPPORT_DIA_HANDERA. Ensure that you have a sects.h file that correctly sets the code sections for DIA_SECTION and RESIZE_SECTION. If your application doesn't do sectioning, you can just do: #define DIA_SECTION #define RESIZE_SECTION You also need to ensure that you have defined SafeMemPtrNew() and SafeMemPtrFree() code and you have prototypes for these in util.h. SafeMemPtrFree() should return if fed a NULL pointer, else call MemPtrFree(), and SafeMemPtrNew() should produce a fatal application error if MemPtrNew() fails. If you don't care about error checking, you can always do something like: #define SafeMemPtrNew MemPtrNew #define SafeMemPtrFree( p ) if ( ( p ) != NULL ) MemPtrFree( ( p ) ) 2. In your application initialization (E.g., StartApplication()) code, call InitializeResizeSupport( indexDIADataID ) make sure this happens before the event handlers for your forms are set. In your application de-initialization, call TerminateResizeSupport(). 3. Before setting the event handler for form formID, call SetResizePolicy( formID ). 4. In each form handler that you want to support DIA, make sure that your winEnterEvent, winExitEvent, frmOpenEvent, frmCloseEvent and winDisplayChangedEvent handlers each call the appropriate resize handler, namely one of: Boolean ResizeHandleWinEnterEvent( void ) RESIZE_SECTION; Boolean ResizeHandleWinExitEvent( void ) RESIZE_SECTION; Boolean ResizeHandleFrmOpenEvent( void ) RESIZE_SECTION; Boolean ResizeHandleFrmCloseEvent( void ) RESIZE_SECTION; Boolean ResizeHandleWinDisplayChangedEvent( void ) RESIZE_SECTION; These routines always return true. Note that ResizeHandleFrmOpenEvent() and ResizeHandleWinEnterEvent() should be called before doing anything yourself (e.g., drawing a form) in the frmOpenEvent and winEnterEvent handlers, and ResizeHandleFrmCloseEvent() and ResizeHandleWinExitEvent() should be called after doing any cleanup you wish to do. 5. Modify your .rcp file to include information on how to resize forms. This is done by including a number of WORDLIST (wrdl) resources. The first and the only non-optional one is an index resource of word pairs. WORDLIST ID indexDIADataID BEGIN fromID1 toID1 fromID2 toID2 ... END The ID indexDIADataID is the same as the one in the InitializeResizeSupport() call. The list of word pairs then each contains the ID of a form resource followed by the ID of the WORDLIST resource that contains the DIA resize data for that form. DIA is disabled for any forms not listed in the index: virtual graffiti is popped up and resize is disabled if possible. It is perfectly acceptable to have no forms in the index or not all of them. Unless this conflicts with other WORDLIST IDs you might be using, it is easiest to use the same ID for the resize data as for the form, so PalmBible+'s index, for instance, starts: frmMainfrmMain frmVersionInfo frmVersionInfo frmMemoEditfrmMemoEdit 6. Now include specific information on how to resize the forms in your application. You should #include resizeconsts.h in your .rcp file to define various bitmapped flags. Each set of information has the following format: WORDLIST ID resizeFormID BEGIN formFlags binNumber preferredState // Object data objectNum1 flags1 0 objectNum2 flags2 0 ... END formFlags is either 0 or a combination of: DIA_FORM_KEEP_LAST DIA_FORM_USE_BIN DIA_FORM_NO_RESIZE These flags, as all flags, can be added together, e.g.: DIA_FORM_KEEP_LAST + DIA_FORM_USE_BIN DIA_FORM_KEEP_LAST: The form keeps the DIA state
Re: DIA support
On Tue, Apr 13, 2004, Alexander R. Pruss wrote: Well, I've got full DIA support in PalmBible+. Now it's time to do it in Plucker. Given that people have been asking for Palm DIA support for half a year, any chance the support could make it into HEAD despite the feature freeze? Sure, but before it is included I'd like to review a diff, i.e. when you have something ready to be included in cvs, please run 'cvs diff -u' and send me the output. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA support
From: Michael Nordstrom [EMAIL PROTECTED]
Sure, but before it is included I'd like to review a diff, i.e. when
you have something ready to be included in cvs, please run 'cvs diff
-u' and send me the output.
Will do. I'm still bug hunting in the general resize routines. Getting
modal forms to work just right is a big nuisance because to do it best I may
have to distinguish between a real win{Exit,Enter}Event and a fake one that
occurs when DIA is resized. I could do it by looking at the winEnter and
winExit values, but I would have to access the inside of the structures to
check if I'm dealing with windows or forms, and PalmSource doesn't want one
to look inside internal structures (plus last time I did that I got memory
errors in the simulator--but maybe I did something wrong). My current
solution seems to work fine without my having to make these distinctions,
but there may be some bugs still in it. Fortunately, some other members of
the PB+ core team are banging on the code. Alex
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA
It sounds, then, that my method will still be compatible with cobalt and will be easy to adapt to working with it more natively. So I guess I'll implement it, first for PB+, and then for Plucker. Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA
I have, however, been thinking about a generalized way of doing DIA that might even be better than using CollapseUtils. For each object on each form, we set a bunch of possible attributes. The DIA shipping on the T3 (codenamed Hawkeye) changed again in Cobalt (6.x). I would only be marginally concerned that this API that we come up with, is still going to be compatible with their new API in these revisions of the OS. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA
At 05:52 PM 4/8/2004, you wrote: I have, however, been thinking about a generalized way of doing DIA that might even be better than using CollapseUtils. For each object on each form, we set a bunch of possible attributes. The DIA shipping on the T3 (codenamed Hawkeye) changed again in Cobalt (6.x). I would only be marginally concerned that this API that we come up with, is still going to be compatible with their new API in these revisions of the OS. The Hawyeye DIA API has never been made public. It's only used in PalmOne's own apps that those that are bundled with the device. Everything else requires the DIA 1.2 compatibility PRC files. DIA 1.2 also works on the TapWave Zodiac, and should work on future OS 5 devices that support non-rectangular screens. Palm OS Cobalt is simpler to support than the previous DIA implementations -- while DIA 2.0 is backwards-compatible with DIA 1.2, but it also supports window constraint resources that let you tell the OS how your window resizes -- you specify the maximum, minimum, and preferred values for widths and heights, and the OS automatically resizes your form. You also get to use FrmInitLayout to tell the OS how it should move objects around in your form -- what's tied to the sides of the form, what resizes, etc. -- Ben Combee, senior DTS engineer, PalmSource, Inc. Read Combee on Palm OS at http://palmos.combee.net/ ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
DIA and palm vs GPL
You're talking about the SampleCollapse code, right? I just checked, and here's the license: You may incorporate this sample code (the Code) into your applications for Palm OS(R) platform products and may use the Code to develop such applications without restriction. The Code is provided ... You are not permitted to redistribute the Code on a stand-alone basis and you may only redistribute the Code in object code form as incorporated into your applications. I suspect this comes from two concerns, and they may be more likely to relicense if you address them: (1) They want to lock you into the palm; you can't take their code and make a similar program for PocketPC. If this code is both small and heavily dependent on the Palm API, it may not be useful on other devices anyhow. So they might be willing to dual license *this*, even if they are not willing to do the same with larger programs like memopad. Note that a dual license offers more flexibility than a relicense; many of the unwanted users would be unwilling to open their own code with GPL, and would therefore still be bound by the current license. People using a BSD-style license can legitimately ship object-code only, with a reference to where the source code can be found. (2) They want developers to register, so that they can brag about large numbers, and maybe send you marketing stuff. I suspect that the number of people who want to use the DIA but don't want to register and don't need other tools (like the SDK, or ROM images) is fairly small, and losing those few names might be worth it to improve the available software. -jJ ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: DIA and palm vs GPL
They have nothing to lose. After all, if they say no, we can just do a clean-room rewrite--it's a tiny piece of code. In my experience, if you offer to do a cleanroom rewrite from the start, there is no incentive for them to cooperate and provide a dual license or relicensing arrangement. They'll just wait for you to do it on your own. No risk to them, and all the risk to you, should they decide to come down on you to defend the origins of your code. d. ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
