Ok, I've got a problem with mui owb were if I download more than 2 images mui owb freezes. This happens in any forum or Photobucket type site. The only way I can continue is to reset.
and if possible it can be fixable on future OWB versions, but before open a bugreport you should provide the link and all the info needed for reproduce the bug step by step
I've never seen anything like that. I've downloaded many many images after each other in MUI-OWB without any problems. My only problem is the annoying file requester that always open without anyway of bypassing. I'll fix that if Fab hasn't already.
The only thing that typically freeze it in update 3 is if it runs out of memory and the swapper fails, which it tends to do in update 3.
Please tell me your memory usage while you are doing this or provide a link when it can be reproduced. And how my RAM do you have?
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
My only problem is the annoying file requester that always open without anyway of bypassing. I'll fix that if Fab hasn't already.
On my system, the file requester opens on WorkBench even though I am using MUI-OWB on a different Public screen. Can you make it open on the same screen as MUI-OWB? Please don't completely remove the file requester; I frequently rename downloads that have peculiar names.
@Deniil Could you also change the OWB-MUI port name?? A number of people are using RA-OWB and MUI-OWB simultaneously and they both have the same port name which is bound to cause a problem eventually. Right now opening Ranger on my system lists two seperate OWB.1 ports; one for RA-OWB and the other for MUI-OWB
Please don't completely remove the file requester; I frequently rename downloads that have peculiar names.
I think i not understand what you trying to say, but for what we should remove it at all ?:) That should be pretty easy to fix
Quote:
Could you also change the OWB-MUI port name?? A number of people are using RA-OWB and MUI-OWB simultaneously and they both have the same port name which is bound to cause a problem eventually. Right now opening Ranger on my system lists two seperate OWB.1 ports; one for RA-OWB and the other for MUI-OWB
Should be trivial to change of course.
Thanks for filling the bug-reports on bugs.os4depot, that will help a lot. We for now start to worring about fixing of bugs and better if they will be on one place and well described: on bugs.os4depot.net :)
Right now build some new fresh version and do some testing, hope for update4 we will have new version of muiowb (bug-fixed one) as well as fixes in the mui itself.
May I understand that we should wait for update 4 to have a new version of MuiOWB ?
As update4 will have fixes in the MUI itself, then of course, muiowb (even current one) will works better. But if all will going well, i hope to release some bug-fixed version as well from the muiowb side (i.e. fixed fontconfig, threaded curl or just plain network threading, working npapi part with swfdec port, fixing of bugs from bugs.os4depot.net and so on).
No I won't remove the file requester, just add another option "Save image" as a complement to "Save image as...".
Of course it should open on the same screen as OWB. Strange that it doesn't. If it is a MUI asl requester it is a bug in MUI, otherwise an oversight by Fab I guess, or an incompatibility between MOS/OS4 file requesters.
Changing the port name is easy, but it will render all existing MUI-OWB scripts useless (if there are any). Maybe it could be optional for the OS4 version of OWB.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
I think i not understand what you trying to say, but for what we should remove it at all ?:) That should be pretty easy to fix
Deniil stated: "My only problem is the annoying file requester that always open without anyway of bypassing. I'll fix that if Fab hasn't already." I misunderstood his statement and thought he might be fixing the problem by removing the requester altogether. However, he has clarified his intent and wants to have a "save" and "save-as" option for downloading. Sorry for the misunderstanding.
Of course it should open on the same screen as OWB. Strange that it doesn't. If it is a MUI asl requester it is a bug in MUI, otherwise an oversight by Fab I guess, or an incompatibility between MOS/OS4 file requesters.
The only true MUI file requester (ASYNCHRONOUS) I know of (in MUI 3.8/3.9) is PopASL which is designed to be opened from a button or such. The MUI_AslRequest() function just just calls a standard ASL requester and is therefore SYNCHRONOUS and blocks Intuition updates of the program window. Maybe MUI 4 in MOS has remedied that situation but not in OS4 MUI. If you start a download in muiowb, the download manager window is not updated while the file requester is open. Try resizing the download manager window while the file requester is open and you will see that the window contents are not refreshed. That is evidence that a standard (SYNCHRONOUS) Asl requester is being used. In that case, the programmer needs to specify the screen for the requester to open on instead of relying on MUI to do the right thing and open the requester on the same screen as the program.
EDIT: I think that either the ASLFR_Window() or ASLFR_PubScreenName() or ASLFR_Screen() Tag needs to be added to the Asl_FileRequest() function call to get the requester on the right screen. It might not be a bad idea to put the download manager window to sleep (MUIA_Application_Sleep() ??) so the user will know that the window is not accepting input until the requester is closed (busy pointer displayed).
Changing the port name doesn't make much sense, just as using the two OWB flavours at the same time doesn't.
As for the ASL requester, it's definitely a difference in behaviour in MUI OS4, because here, it always opens on the screen it was called on. Of course, you can always force it to whatever screen you want with additional tags, but it shouldn't be needed here.
And yes, the requester is synchronous (with a bit of work, it could be made asynchronous, but it's less trivial than it sounds, because you would need to wire that to some webkit events as well). But in any case, the application (and thus all subwindows) are explicitely set to sleep, currently, so they should really show the busy pointer.
As for the random crashes when downloading images, they're definitely specific to OS4, and i really fail to see what could happen there, actually.
And a bit off-topic: all these issues with MUI getting suddenly small/unreadable fonts is in my opinion related to the tabs and/or URL poplist having too long titles/URLs. In OWB MorphOS version, the tab title is truncated if needed, and MUI4 lists have an horizontal scrollbar. Too long items won't cause any kind of layout issue, which is apparently not the case in MUI OS4 list. If that's the case, it will be trivial to manually truncate the offending URL/titles (there are functions for that in my API if needed).
As for the ASL requester, it's definitely a difference in behaviour in MUI OS4, because here, it always opens on the screen it was called on. Of course, you can always force it to whatever screen you want with additional tags, but it shouldn't be needed here.
MUI is probably better integrated into MOS and it may be necessary to add the additional tag to get the desired behavior on OS4. If the Asl requester in muiowb is called by the MUI_AslRequest() function instead of by a direct call through asl.library then the maintainer of MUI for OS4 may need to add the necessary tag (unless it was a concious decision to leave the screen tag up to the calling program). Quote:
And yes, the requester is synchronous (with a bit of work, it could be made asynchronous, but it's less trivial than it sounds, because you would need to wire that to some webkit events as well). But in any case, the application (and thus all subwindows) are explicitely set to sleep, currently, so they should really show the busy pointer.
In the case of a download it's probably better for the file requester to be synchronous so that the user is more likely to give it his immediate attention and complete or cancel the download. Both the main muiowb window and dowload manager window do appear to be "sleeping" but don't display the standard Amiga "busy" pointer when they are activated. If you click on the main window while the file requester is open, a "gloved hand" pointer is displayed and when if you click on the download manager window, the standard arrow pointer is still displayed.
I don't get why the windows doen't show the sleepy pointer if MUIA_Application_Sleep is set. However, if you, Fab, expect MUI_AslRequest to automatically set the sleep on the app when an asl is openen, then it's a bug/lack of feature in OS4 MUI.
MUI should automatically set the app to sleep when it knows it will perform a blocking (synchronous) action, such as opening asl. The same applies to putting requesters on the correct app screen, unless the user forces to another screen or WB.
@kas1e: We need to look at this a make bug reports to Thore if necessary.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
MUI is probably better integrated into MOS and it may be necessary to add the additional tag to get the desired behavior on OS4. If the Asl requester in muiowb is called by the MUI_AslRequest() function instead of by a direct call through asl.library then the maintainer of MUI for OS4 may need to add the necessary tag (unless it was a concious decision to leave the screen tag up to the calling program).
As i see in the muiowb sources, for aslrequest used exactly MUI_AslRequestTags, so, i send the necessary info to Thore, hope he will fix it.
@Deniil Quote:
I don't get why the windows doen't show the sleepy pointer if MUIA_Application_Sleep is set. However, if you, Fab, expect MUI_AslRequest to automatically set the sleep on the app when an asl is openen, then it's a bug/lack of feature in OS4 MUI.
As i see in the muiowb sources, fab do not expect this, because (in asl.cpp):
Quote:
req = MUI_AllocAslREquestTags blablalbalbla
if (req) { set (app, MUIA_Application_Sleep, TRUE); blablabl }
Imho its all sets manually when its need it (i.e. while asl req is open), and its not done automatially, but by the code of muiowb.
Quote:
We need to look at this a make bug reports to Thore if necessary
Yep, i already send the report about MUI_AslRequest.
But related to MUIA_Application_Sleep imho there is no bugs, i.e. try to "open file", and then while you have Asl-req open, press on main owb button : there will be busy pointer. Imho it should't be automatic, because by default you have asl-req active (so no busy pointer should be).
But related to MUIA_Application_Sleep imho there is no bugs, i.e. try to "open file", and then while you have Asl-req open, press on main owb button : there will be busy pointer. Imho it should't be automatic, because by default you have asl-req active (so no busy pointer should be).
It does work properly when you select "open file" but not when you are downloading an image. If you move the pointer over an image, press the menu button to open the popup menu and select "Save Image As" then there is no sleep pointer when you click on the muiowb window or the download manager window after the Asl requester opens. When you click on the muiowb window a link pointer (gloved hand) pointer is displayed and when you click on the download manager window a standard arrow pointer is displayed. Both windows should be displaying a sleep pointer since they are obviously "sleeping" and not responding to user input.
P.S. I had to post this with RA-OWB because Amigan.net will not log me in from muiowb. I must have selected "Remember Me" in RA-OWB because I am automatically logged in when I access Amigans.net with RA-OWB. When I attempt to log in with muiowb, Amigans.net shows the window saying "Thanks for logging in xenic" but when the home page is reloaded I am not logged in. I wonder if this is a problem caused by using two different browsers with the same name and port names or is it an Amigans.net bug??
It does work properly when you select "open file" but not when you are downloading an image. If you move the pointer over an image, press the menu button to open the popup menu and select "Save Image As" then there is no sleep pointer when you click on the muiowb window or the download manager window after the Asl requester opens. When you click on the muiowb window a link pointer (gloved hand) pointer is displayed and when you click on the download manager window a standard arrow pointer is displayed. Both windows should be displaying a sleep pointer since they are obviously "sleeping" and not responding to user input.
Aha ok, i understand. Now just need confirmation from Fab that is bug of os4 version, or, the same happens on morphos as well.
Quote:
P.S. I had to post this with RA-OWB because Amigan.net will not log me in from muiowb. I must have selected "Remember Me" in RA-OWB because I am automatically logged in when I access Amigans.net with RA-OWB. When I attempt to log in with muiowb, Amigans.net shows the window saying "Thanks for logging in xenic" but when the home page is reloaded I am not logged in. I wonder if this is a problem caused by using two different browsers with the same name and port names or is it an Amigans.net bug??
Have the same problems sometime on Firefox and Crhome on winxp, as well as fab do fixes in the cookies-related code which can make a sense. But once i normally select "remember me", and "save the cookie" in muiowb, that all fix the problems.
OK its been a few days but i finally got round to reproducing the crash again today. I'm using a Sam460 with 2gb of ram.
With no other programs open i.e.tunenet etc, i can save 2 images through muiowb but on attemtping a third it freezes.
This happens on any site with photos, i.e. photobucket, google albums, any forums.
Here is the crashlog:
Crash log for task "OWB" Generated by GrimReaper 53.2 Crash occured in module intuition.library.kmod at address 0x019E32BC Type of crash: DSI (Data Storage Interrupt) exception
I'm waiting for my account to be registered on os4depot before posting a bug report thats why i thought id post the crashlog here.
Till now you can delete everything from the bottom, till the "PPC disassembly" words. I.e. all what come after that words, no so need it. The only "stack trace" are important in general.
Related to crashlog itself, yeah, looks like mui-bug, but i need to reproduce it normally, before sending the bug-report to Thore.
Btw, just in case, lately we found some bug in "adding of scrollbars to groups", which crashlogs looks pretty the same as this one. So, if you have some time, can you please test this:
go to mui prefs, lists, and set for scrollbards "NEVER" (but not "automatical" as it by default). Save, reboot, run muiowb, and try to do all what you do again and again. IF there will be no crashes, then its the same bug (good for us), if crash will be still here, then its different bug.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
