@kas1e
I saw the posts about the Dopus5.guide and help system at Amigans.net. The guide we're including is not the latest guide and the original DOpus5 CD also had an ARexx guide. I'm going to clean up the latest guides (copyrights etc.) and place them in the repository. I'm thinking about putting them in the root/Documents directory and copying them to the archive in the main makefile. What do you think??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@tomsmart1
I thought there would be affects on other platform too. On OS4 the "avail flush" command was removed so the average user has no way of flushing libraries. However, trying to flush the library won't help unless the library open count goes to zero. I don't know what BSzili did to fix the patch removal but hopefully he will read these posts and comment on the problem.
Last edit: xenic 2014-05-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@all
I did some more testing and it seems like there is no problem with the dopus/PatchEBInfo variable set if I don't use WBInfo on Workbench. Also, when I use WBInfo on Workbench and close Dopus5, the Dopus5 screen shuts down but Ranger shows that the Dopus5 program is not completely exiting. So far I can't tell if it's a patch issue in the library or a problem in the program.
EDIT: Dopus4 calls WBInfo (without any patching) and uses the DOpus5 WBInfo when the dopus/PatchEBInfo is set and Dopus5 is running. Opening a WBInfo window with Dopus4 does not cause a problem with closing and reopening Dopus5. It appears that the problem only occurs when WBInfo is used with Workbench; strange??
Last edit: xenic 2014-05-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I saw the posts about the Dopus5.guide and help system at Amigans.net. The guide we're including is not the latest guide and the original DOpus5 CD also had an ARexx guide. I'm going to clean up the latest guides (copyrights etc.) and place them in the repository. I'm thinking about putting them in the root/Documents directory and copying them to the archive in the main makefile. What do you think??
Of course we need latest guides and we need to include arexx guide too. Also clean them all with all last info are good idea too.
Dunno through what we should choice HELP or Documents directory. In HELP we have now all guides, and they taken from by dopus5 code when need it. So probably all guides should be copies to HELP directory. Probably we need to create HELP directory on repo too to avoid mess later ?
Last edit: kas1e 2014-05-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
I committed the changes. I removed the guides and pdf docs from the base archive (basedata.lha) and added the the new amigaguides to the trunk/Documents directory. I changed the makefile to copy the amigaguide files to Dopus5/Help in the release archive and the pdf docs to Dopus5/Documents in the release archive. Since we keep saying we will update the docs for changes we make to Dopus5, we won't need to keep changing the base archive (basedata.lha) every time the docs are changed. The latest docs will be copied into the release archive. If you want to change where the guides are located latter, I don't really care where they are as long as they get copied to the archives for overnight compiles and releases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@all
Forget about the problem with the WBInfo patch if the dopus/PatchWBInfo variable is set. I found the problem, fixed it and committed the changes. It's one less problem now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
make[1]: Leaving directory `/home/dopus5/trunk/source/Misc/C'
>>>>>Creating release archive: Dopus5_91_dev_os4_debug.lha
cp: cannot stat `../Documents/*.guide': No such file or directory
make: *** [release] Error 1
BUILD SVN VERSION IS: rev.1034M
(same for all oses).
Bwt, i also think what will be the best way to create a 5.9x docs. Probably we better make DOpus5.9x.pdf where note all the changes and addonts and do it in the same way/look as it was done by original authors in dopus582.pdf ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
P.S. If you want to force the Dopus5: assignment for all platforms we can just comment out the check for existing Dopus5: assignment in Program/main.c.
Probably we should do that and for morphos and for aros too. Because , users may mess their system, and in general there imho no reassons to not do that. Because assignment always should point on progdir: of dopus5 root dir. Dunno what was the reassons for check it initially.
Bszili, are you ok if we will force dopus5: assign and for aros too? (just less ifdefs, the better).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It didn't fail when I tested it on my system because AmigaDOS isn't case sensitive. I need to change some of the "Documents" to "documents" with lower case "D". I'll change it before the next nightly build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@BSzili
I don't understand. The patchs in your post (like Dopus5/Buttons/toolbar) look correct to me. What are the paths when they are broken? That being said, sometimes archives that I create with Dopus4 don't work right with other lha commands. I think Dopus4 recurses directories and adds them to the archive instead of letting lha recurse the directory and add them to the archive. I'll try recreating the basedata.lha on a shell command line and commit it to see if it makes a difference.
EDIT: Kasle posted while I was editing my post. I'll let kas1e fix the basedata.lha archive since he made the previous ones that work for everyone.
Last edit: xenic 2014-05-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Xenic
Btw, why there is needs to have PatchWBInfo variable at all ? I mean, as far as i can see visually, when i set that variable, or when i not set that variable, everything looks the same when i press on icon and choice "information".
The only difference i see, its when i not have that variable, but set UseWBInfo: then, i see OS version of information (cool btw). And when i set together with that PatchWBInfo, then it make 'information' looks via dopus again. But then, why we need that variable, if we can just remove UseWBInfo, and so, have dopus one back again ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
Dopus5 uses it's WBInfo window regardless of the PatchWBInfo settings. The PatchWBInfo changes WBInfo for the whole system. If you set the PatchWBInfo variable, Dopus4 also uses the Dopus5 WBInfo window when you perform IconInfo. Any program that calls WBInfo will get the Dopus5 WBInfo window with the patch set. If you are running Dopus5 on it's own screen but not in Workbench replacement mode, the WorkBench Icons/Information menu also brings up the Dopus5 WBInfo window (instead of RAWBInfo window on OS4).
Using the Dopus5 WBInfo window might be a very good option on platforms (AROS, OS3 etc.) that don't have RAWBInfo as part of the OS. Just open your Exchange window and make RAWBInfo "inactive" and then select the Icons/Information menu with an icon selected on the WorkBench screen. You will see the ugly old WorkBench WBInfo window. That's what other platforms will see if RAWBInfo is not installed and the Dopus5 PatchWBInfo variable isn't set.
The bottom line is that we shouldn't be removing user options that work and might be useful for some users. That's especially true when we have serious problems to fix in Dopus5. Now that I fixed the PatchWBInfo option, just leave it alone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Damn, seems i delete post i wrote. So will re-type:
Thanks for explain, all clear now. But i didn't find in our pdfs any info about PatchWBInfo , probably we need to document it later as well in our new pdf ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for explain, all clear now. But i didn't find in our pdfs any info about PatchWBInfo , probably we need to document it later as well in our new pdf ?
I checked the code again and if the PatchWBInfo variable is not set, the WBInfo patch just calls the old builtin WorkBench WBInfo. That means the WBInfo patch is doing nothing useful without the variable set. If you want to eliminate the PatchWBInfo variable, then we can just get rid of that patch and have one less patch to worry about. Since it's not documented maybe nobody would miss it and I may have protested to strongly in my previous post. I think you should ask BSzili and possibly some users if we can get rid of PatchWBInfo and remove that hook. I would ask users privately since in a forum somebody will always say they want some feature even if they don't use it.
I would leave the PatchWBInfo variable out of the docs until you decide if you want to eliminate it. If you decide we don't need it then I would wait until all the other bugs and problems are fixed before eliminating or changing patches. Since I fixed the OS4 crash in the WBInfo patch, it's not a problem to leave it there for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm kind of on the fence about this. In WBR mode it could make sense to have the icon.module WBInfo window everywhere, so you can d&d icons, etc. On the other hand, just how many programs are there which use the WBInfo function?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@all
imho as all works now, lets it be here for now. we always can comment code, but as it works now let it be here, more functional better (at least for now)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
Sounds about right, having one more optional patch doesn't really compromise the stability of the program, and some users might prefer to use it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok i test the nightbuild from 2010515 with The ENV PatchWBInfo it works now no frezes after Avail Flush and the Patches nearly all remove by exprung only 2 are not removed that are the patches of the graphics.library at offset -606 and -636 form DirectoryOpus
I see it like that all patches by wb.c are removed Scout show it all as Patcher "DO_Launcher".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, I'm making some changes to problems I discovered while searching for 64bit solutions. There are a number of places where an OS4 library interface is opened after an "if OpenLibrary()" and exits < (exit(0) > if the interface opening fails. However, other platforms continue with "else" sections or other code if the library opening fails. I'm going to fix those situations so that OS4 proceeds like the other platforms. Those exit(0) statements may have been a shortcut to get everything ported to GCC but they need to be fixed now. An example is the about module. Before I fixed it, other platorms would show a simple requester if the about.module couldn't be opened but the OS4 version would just exit and do nothing if the about.module couldn't be opened and the interface added.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Xenic
Btw, i check latest commits, so far all looks good about versions checks, etc. I even tried to open dopus5.91 on os3 while running sasc's 5.82, and it says "can't open dopus5.library!", which is good. I play a bit with it there and there, and imho it will worth to add library/modules versions/revision in the warning windowses. I.e. not just "can'n open dopus5.library!", but "can't open dopus5.lirary vXX.XX !" , so that will be more understandable what going on.
I also play with os4 version and trying to do some mess:
Firstly, i just put sasc's 68k about.module => it just skips, and dopus5 loads fine, just when i do "about" it show me a bit lighter version of about. So far its good.
Then, i replace configopus.module, by sasc's 68 version: dopus5 loads fine, but when i go to environment , it just says "an error occured opening 'configopus.module'. Also good enough (as no crash).
Next thing, its i replace xadopus.module with sasc 68k one, and when i dbl-click on archive nothing happens. No warnings, nothing, just didn't works. But , no crash either, and via ranger i can see that 68k xadopus.module didn't loads too. So , all fine there as well.
And last thing i try, its just download some 68k-assmebler-based module called "rootparent", put it to the "Modules" , and , it loads , i can see it in the ranger. But, probably that because we currently didn't have code which exclude 68k modules for ppc builds.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
We can only be responsible for the Dopus5 modules. If the user want to experiment with old modules on a new Dopus5, then any negative results are the user's problem and caused by the user. I told you that I could make the version checks for all modules so those old modules won't get opened but you didn't want that. The rootparent module is opened but not being used. The rootparent module will not be opened if I change the version checks to check all modules instead of just our modules. If you want me to expand the version checks for all modules I'll do that. If that won't make you happy then I'm done with this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
I saw the posts about the Dopus5.guide and help system at Amigans.net. The guide we're including is not the latest guide and the original DOpus5 CD also had an ARexx guide. I'm going to clean up the latest guides (copyrights etc.) and place them in the repository. I'm thinking about putting them in the root/Documents directory and copying them to the archive in the main makefile. What do you think??
@tomsmart1
I thought there would be affects on other platform too. On OS4 the "avail flush" command was removed so the average user has no way of flushing libraries. However, trying to flush the library won't help unless the library open count goes to zero. I don't know what BSzili did to fix the patch removal but hopefully he will read these posts and comment on the problem.
Last edit: xenic 2014-05-12
@all
I did some more testing and it seems like there is no problem with the dopus/PatchEBInfo variable set if I don't use WBInfo on Workbench. Also, when I use WBInfo on Workbench and close Dopus5, the Dopus5 screen shuts down but Ranger shows that the Dopus5 program is not completely exiting. So far I can't tell if it's a patch issue in the library or a problem in the program.
EDIT: Dopus4 calls WBInfo (without any patching) and uses the DOpus5 WBInfo when the dopus/PatchEBInfo is set and Dopus5 is running. Opening a WBInfo window with Dopus4 does not cause a problem with closing and reopening Dopus5. It appears that the problem only occurs when WBInfo is used with Workbench; strange??
Last edit: xenic 2014-05-12
@Xenic
Of course we need latest guides and we need to include arexx guide too. Also clean them all with all last info are good idea too.
Dunno through what we should choice HELP or Documents directory. In HELP we have now all guides, and they taken from by dopus5 code when need it. So probably all guides should be copies to HELP directory. Probably we need to create HELP directory on repo too to avoid mess later ?
Last edit: kas1e 2014-05-13
@kas1e
I committed the changes. I removed the guides and pdf docs from the base archive (basedata.lha) and added the the new amigaguides to the trunk/Documents directory. I changed the makefile to copy the amigaguide files to Dopus5/Help in the release archive and the pdf docs to Dopus5/Documents in the release archive. Since we keep saying we will update the docs for changes we make to Dopus5, we won't need to keep changing the base archive (basedata.lha) every time the docs are changed. The latest docs will be copied into the release archive. If you want to change where the guides are located latter, I don't really care where they are as long as they get copied to the archives for overnight compiles and releases.
@all
Forget about the problem with the WBInfo patch if the dopus/PatchWBInfo variable is set. I found the problem, fixed it and committed the changes. It's one less problem now.
@xenic
Yeah, all good. Through nightly builds fail with:
(same for all oses).
Bwt, i also think what will be the best way to create a 5.9x docs. Probably we better make DOpus5.9x.pdf where note all the changes and addonts and do it in the same way/look as it was done by original authors in dopus582.pdf ?
@Xenic
Probably we should do that and for morphos and for aros too. Because , users may mess their system, and in general there imho no reassons to not do that. Because assignment always should point on progdir: of dopus5 root dir. Dunno what was the reassons for check it initially.
Bszili, are you ok if we will force dopus5: assign and for aros too? (just less ifdefs, the better).
@kas1e
It didn't fail when I tested it on my system because AmigaDOS isn't case sensitive. I need to change some of the "Documents" to "documents" with lower case "D". I'll change it before the next nightly build.
Both environments (default, workbench) in basedata.lha have broken paths, like:
This causes some problems when someone tries to load them.
yep will fix tomorrow
@BSzili
I don't understand. The patchs in your post (like Dopus5/Buttons/toolbar) look correct to me. What are the paths when they are broken? That being said, sometimes archives that I create with Dopus4 don't work right with other lha commands. I think Dopus4 recurses directories and adds them to the archive instead of letting lha recurse the directory and add them to the archive. I'll try recreating the basedata.lha on a shell command line and commit it to see if it makes a difference.
EDIT: Kasle posted while I was editing my post. I'll let kas1e fix the basedata.lha archive since he made the previous ones that work for everyone.
Last edit: xenic 2014-05-14
@Xenic
Btw, why there is needs to have PatchWBInfo variable at all ? I mean, as far as i can see visually, when i set that variable, or when i not set that variable, everything looks the same when i press on icon and choice "information".
The only difference i see, its when i not have that variable, but set UseWBInfo: then, i see OS version of information (cool btw). And when i set together with that PatchWBInfo, then it make 'information' looks via dopus again. But then, why we need that variable, if we can just remove UseWBInfo, and so, have dopus one back again ?
@kas1e
Dopus5 uses it's WBInfo window regardless of the PatchWBInfo settings. The PatchWBInfo changes WBInfo for the whole system. If you set the PatchWBInfo variable, Dopus4 also uses the Dopus5 WBInfo window when you perform IconInfo. Any program that calls WBInfo will get the Dopus5 WBInfo window with the patch set. If you are running Dopus5 on it's own screen but not in Workbench replacement mode, the WorkBench Icons/Information menu also brings up the Dopus5 WBInfo window (instead of RAWBInfo window on OS4).
Using the Dopus5 WBInfo window might be a very good option on platforms (AROS, OS3 etc.) that don't have RAWBInfo as part of the OS. Just open your Exchange window and make RAWBInfo "inactive" and then select the Icons/Information menu with an icon selected on the WorkBench screen. You will see the ugly old WorkBench WBInfo window. That's what other platforms will see if RAWBInfo is not installed and the Dopus5 PatchWBInfo variable isn't set.
The bottom line is that we shouldn't be removing user options that work and might be useful for some users. That's especially true when we have serious problems to fix in Dopus5. Now that I fixed the PatchWBInfo option, just leave it alone.
@Xenic
Damn, seems i delete post i wrote. So will re-type:
Thanks for explain, all clear now. But i didn't find in our pdfs any info about PatchWBInfo , probably we need to document it later as well in our new pdf ?
@kas1e
I checked the code again and if the PatchWBInfo variable is not set, the WBInfo patch just calls the old builtin WorkBench WBInfo. That means the WBInfo patch is doing nothing useful without the variable set. If you want to eliminate the PatchWBInfo variable, then we can just get rid of that patch and have one less patch to worry about. Since it's not documented maybe nobody would miss it and I may have protested to strongly in my previous post. I think you should ask BSzili and possibly some users if we can get rid of PatchWBInfo and remove that hook. I would ask users privately since in a forum somebody will always say they want some feature even if they don't use it.
I would leave the PatchWBInfo variable out of the docs until you decide if you want to eliminate it. If you decide we don't need it then I would wait until all the other bugs and problems are fixed before eliminating or changing patches. Since I fixed the OS4 crash in the WBInfo patch, it's not a problem to leave it there for now.
I'm kind of on the fence about this. In WBR mode it could make sense to have the icon.module WBInfo window everywhere, so you can d&d icons, etc. On the other hand, just how many programs are there which use the WBInfo function?
It is a feature to use thie Iconinfo window from Dopus on the normal Workbench it was good a the Time DOpus5 cam out.
@ALL
Nearly all DOPUS ENV variables are documented and there is a program to easy change it with http://aminet.net/package/biz/dopus/Do5extPrefs16 .
@all
imho as all works now, lets it be here for now. we always can comment code, but as it works now let it be here, more functional better (at least for now)
@kas1e
Sounds about right, having one more optional patch doesn't really compromise the stability of the program, and some users might prefer to use it.
Ok i test the nightbuild from 2010515 with The ENV PatchWBInfo it works now no frezes after Avail Flush and the Patches nearly all remove by exprung only 2 are not removed that are the patches of the graphics.library at offset -606 and -636 form DirectoryOpus
I see it like that all patches by wb.c are removed Scout show it all as Patcher "DO_Launcher".
@all
I guess that settles it; it stays :-)
Also, I'm making some changes to problems I discovered while searching for 64bit solutions. There are a number of places where an OS4 library interface is opened after an "if OpenLibrary()" and exits
< (exit(0) >if the interface opening fails. However, other platforms continue with "else" sections or other code if the library opening fails. I'm going to fix those situations so that OS4 proceeds like the other platforms. Those exit(0) statements may have been a shortcut to get everything ported to GCC but they need to be fixed now. An example is the about module. Before I fixed it, other platorms would show a simple requester if the about.module couldn't be opened but the OS4 version would just exit and do nothing if the about.module couldn't be opened and the interface added.@Xenic
Btw, i check latest commits, so far all looks good about versions checks, etc. I even tried to open dopus5.91 on os3 while running sasc's 5.82, and it says "can't open dopus5.library!", which is good. I play a bit with it there and there, and imho it will worth to add library/modules versions/revision in the warning windowses. I.e. not just "can'n open dopus5.library!", but "can't open dopus5.lirary vXX.XX !" , so that will be more understandable what going on.
I also play with os4 version and trying to do some mess:
Firstly, i just put sasc's 68k about.module => it just skips, and dopus5 loads fine, just when i do "about" it show me a bit lighter version of about. So far its good.
Then, i replace configopus.module, by sasc's 68 version: dopus5 loads fine, but when i go to environment , it just says "an error occured opening 'configopus.module'. Also good enough (as no crash).
Next thing, its i replace xadopus.module with sasc 68k one, and when i dbl-click on archive nothing happens. No warnings, nothing, just didn't works. But , no crash either, and via ranger i can see that 68k xadopus.module didn't loads too. So , all fine there as well.
And last thing i try, its just download some 68k-assmebler-based module called "rootparent", put it to the "Modules" , and , it loads , i can see it in the ranger. But, probably that because we currently didn't have code which exclude 68k modules for ppc builds.
@kas1e
We can only be responsible for the Dopus5 modules. If the user want to experiment with old modules on a new Dopus5, then any negative results are the user's problem and caused by the user. I told you that I could make the version checks for all modules so those old modules won't get opened but you didn't want that. The rootparent module is opened but not being used. The rootparent module will not be opened if I change the version checks to check all modules instead of just our modules. If you want me to expand the version checks for all modules I'll do that. If that won't make you happy then I'm done with this issue.
@xenic
let it be as it now, its fine enough already