@samo79

All i know is this its quite ironic that one of the most important pieces of software for os4 is really due to the work/help of morphos people. The opposite would never happen. My point is all those here who made up stories and lies about morphos team should apologize thats all. Apparently people are NOT willing to give these guys credit and admit they were wrong.

@realize

That's not true, many OS4 developers wrote software that in some way comes also on MorphOS and viceversa, for example YAM and SimpleMail are (actually) mostly developed by OS4 mantainers, aniway you are completely off topic, stop flame.

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@realize

Are you so bored with your life that you got nothing better to do than try and start flame wars in every other thread?

@samo79

Current developers (Langner and Boeckel) are OS4 developers/beta testers but YAM is really OS3 software.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@samo79
Quote:

Clickable labels is already possible on old MUI 3.8 and so on, don't having it (yet) on our MUI OWB port (for OS4) is only caused by a limitation of the actual MUI OWB port, so i ask kas1e if he can add it soon or later, that's it ..

That is limitation of our current List class implementation. In mui4, List have all those clicable titles, but in mui3.x are not, In mui3.x there is only one solution to make them the same (as it done in wookiechat for example) it using NList.

But with our port its not high priority to switch to NList usage, just because its buggy here and here, and bringing new bugs to port because of swithcing from List to NList to only make clickable titles, its not so interesting for now :) Because will need tons of time to fix NList , found and fix those new bugs (which for sure will be present) and so on.

So for now, i just want to have just normall working port :) All that cosmetic like clickable titles,, etc, can come later, as well as mouse-pointers. There is few really important bugs which still need to fix, and we for the last week found-fix nothing. Only yesterday i start to understand something about "why url-history-competition not works as should".

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@samo79

Quote:

There is no one single line of code from MorphOS team or MUI4 developers (only OWB code maded by Fab and most of that code was rewritten to backport it on OS4/MUI 3.9), clickable labels is an old MUI 3.8 features

As Fab said, "most of it" is a bit of a stretch. We added a few 100 lines of code to wrap some new MUI4 classes into containers that MUI3.9 understands basically. Other, heavier stuff, like dynamic help bubbles and dynamic menus were fixed in MUI itself, which is partly why we are going to need an update, being part of update3 or OS4.2, I have no idea.

What is taking so long is small details all over that makes stuff crash unexpectedly, such as accessing array[-9] in a list display function. This is now supported by the new MUI3.9. But there are more problems with bubbles that crash in only some places and context menus that simply fail to show in some other places for whatever odd reason. Keys that don't work in a popdown list, incorrect focus when typing in the URL string, etc....

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@kas1e

Quote:

That is limitation of our current List class implementation. In mui4, List have all those clicable titles, but in mui3.x are not, In mui3.x there is only one solution to make them the same (as it done in wookiechat for example) it using NList. So for now, i just want to have just normall working port :) All that cosmetic like clickable titles,, etc, can come later, as well as mouse-pointers.

Ah intesting i thought it used "internal" class for such labels, so we can consider NList deprecated on MorphOS (almost for that) ?

This MUI4 seems quite intesting, it's shame we can't port it cause "politics" reason, aniway

@Deniil715

Quote:

As Fab said, "most of it" is a bit of a stretch. We added a few 100 lines of code to wrap some new MUI4 classes into containers that MUI3.9 understands basically. Other, heavier stuff, like dynamic help bubbles and dynamic menus were fixed in MUI itself, which is partly why we are going to need an update, being part of update3 or OS4.2, I have no idea. What is taking so long is small details all over that makes stuff crash unexpectedly, such as accessing array[-9] in a list display function. This is now supported by the new MUI3.9. But there are more problems with bubbles that crash in only some places and context menus that simply fail to show in some other places for whatever odd reason. Keys that don't work in a popdown list, incorrect focus when typing in the URL string, etc....

Ok guys, thanks for explain !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@samo79

Quote:

Ah intesting i thought it used "internal" class for such labels, so we can consider NList deprecated on MorphOS (almost for that) ?

On MUI4 List are the same fancy visually as NList , but on mui3.x , List its just plain (as it now), without clickable/sortable tables. So for morphos NList still can be used (for cross-platform reassons), but mui4's List already give that and that, and NList can be not used at all (dunno throughl, if NList have something else , that even mui4's List not have).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@realize

Quote:

All i know is this its quite ironic that one of the most important pieces of software for os4 is really due to the work/help of morphos people.

And what's your role in this piece of software? Why are you upset about it? Let those who are upset speak for themselves, I doubt they need a knight in shining armor protecting them.

Regards,
Joachim Birging

AmigaWorld.Net staff

_________________
Common sense - So rare it's almost like a super power

@all
mui-owb progress:

Deniil found yesterday that problems with wrong url-competition/history-navigation mode because of mui3.x default String class which have some unsupported moments and bugs. So for now we switch to BetterString class, with which all works fine and as should. If our plain String class will be fixed/changed a bit for update3, then we will use it, if no, then BetterString.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Deniil715

Quote:

Other, heavier stuff, like dynamic help bubbles and dynamic menus were fixed in MUI itself

?? What kind of bug? I've just used in past dynamic menu creation/updationg on NoWinED, as for bubblehelp... they worked...

@ShInKurO

Quote:

What kind of bug? I've just used in past dynamic menu creation/updationg on NoWinED, as for bubblehelp... they worked...

Well, for some reason it didn't work. Can't remember what we did to fix it though. The last thing though was that setting MUIA_ShortHelp,1, or MUIA_ContextMenu,1, for a ListObject cause crashes. They must be set for the ListviewObject only. I found that out the hard way last night.

Since MUI-OWB only use List everywhere, no Listview, we had to make a wrapper to add the Listview, but we still sent all tags to the List. Now there is code that moves some tags from the List to the Listview.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

It seems MUI3 has never been tested with such heavy class inheritance/overloading before. MUI-OWB only use inherited classes everywhere, hardly any class is plain directly from MUI.

I think this has revealled a ton of bugs that tboeckel is now busy fixing, or has fixed. I myself rarely subclass anything in MUI unless I really want special behaviour, such as drag'n'drop and crap in a list or a special numeric slider or an image area.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@ShInKurO
where have you been of late?
i have still some minor issues on nowined 68k under zune to report, both the same on afa_os and under aros68k lately. i dont know though if its nowined or mui/zune classes fault.

@Deniil715

Quote:

It seems MUI3 has never been tested with such heavy class inheritance/overloading before. MUI-OWB only use inherited classes everywhere, hardly any class is plain directly from MUI.

Probably because Listview was obsoleted in MUI4 and many other things programming techniques have changed.

Have you thought about writing an article about differences and problems you have found during porting? It could be nice to have MUI3 vs MUI4 differences documented for future use... including wrapper classes and such.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

Have you thought about writing an article about differences and problems you have found during porting? It could be nice to have MUI3 vs MUI4 differences documented for future use... including wrapper classes and such.

Many problems which we found not related to mui3 vs mui4, just related to some real bugs in the mui3 itself. I.e. like for example there was a problem with transfering (as docs say) of all the commands to ListView through List , but in reality MUIM_CreateImage are not , so it was fixed. That not a difference, just a bug.

The other one for example was that for if(DoMethod(...MUIM_List_GetEntry...)), current public mui3.9 always return FALSE and does not matter what , also fixed , but again not a difference, just a bug.

And there was many bugs of such kind (and all those bugs mui3.8 have for sure as well), which was fixed in mui3.9. Dunno if it "differences". Its just crapo-bugs. Without fixing of which, all will be buggy, and workorounds will be very hard.

The real "Differences" (if taking to account that mui3.x will not have any bugs, and they all will be fixed somehow, what is imho never will happens because of legal reassons) are:

1. some List methods in mui4 , works only as hooks in mui3 : List_Display, List_Destruct, List_Construct, List_Compare. They all for now also implemented in the Mui3.9, but, we still use wrapper for it, just because its works as well and maybe can be helpfull if someone will start someday AROS/OS3 port.

2. Negative arrays not supported but mui3.8 at all, and just heavy crashes/memory trashes on it. In our mui3.9 its also implemented for now, but, not working. Just not crashes. For mui3.8 there is will need to add ifdefs to avoid usage of negative arrays (what, can cause later any kind of bugs as well).

3. TABS are not implemented not in mui3.8, not in mui3.9 as well, so TABS are implemted as wrapper , with usage of group objects.

4. Our plain String class suck. Have bugs and no feature-rich in compare with mui4 String class (which are TextInput for now as Fab say). So, there is need to use BetterString (even if all will be fixed in 3.9 version of mui).

And all most of the problems, its just bugs, bugs and bugs. Many of them was fixed in mui3.9, but, i of course notice to a text file everything (i.e. what bugs what cause), so later if someone will start with aros/os3 port, he for sure will have a lot of necessary info.

And even for now, there is still that "random lockup bug", which, very possible can be because of mui as well. For example that String class, ####s with EventHandlers, so , its all can be pretty deep in MUI, what can't be fixed from the user-side.

As verdict, i think that we can write some tutor about it (i even this about making it as some kind of project, in which write everything about that differences related not only to mui3.9 vs mui4, but also to zune and to mui3.8), but its all need to structure, retest, recheck, normally describe , etc ,etc and in end .. the real problems is that most of the problems its just bugs , bugs and one more time bugs in mui code itself (and i not say, that even public mui3.9, without reling to fixes about OWB, have many many fixed bugs in compare with mui3.8).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@itix

Why is YAM "OS3 software"? Please explain.

_________________
Why stop it now, just when I am hating it?

Thore Böckelmann

@tboeckel

It comes from OS3 and does not require anything fancy nor require much effort to compile to OS3.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@all
mui-owb progress:

As Deniil say before, he found yesterday some stuff which cause problems with crashing in some of bubble-helps, and in some of contextmenus, and today we test all of this, and yes, all works as should now. So, all what we need now its:

1. need to fix "curl library port". I build latest version few days ago without threading/tls and all the wrong stuff, but still, need to do some manual work, to make "file://" protocol works with amiga pathes, which will fixes local usage of files, drag and drop of local file to OWB and related stuff.

2. custom mouse pointers (a bit different done on moprhos vs aos4).

3. Random freeze :)

That all imho for now .. We will try to fix first two in next 2-3 days, and then - last fight with Random freeze :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

so...

GOOD WORK!

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.