I believe that if I should connect click of a button with a string for me it's simpler to write:
Well BOOPSI can use ICA_TARGET, which makes linking objects together relatively easy.
Quote:
In the actual state MUI is a third part thing (OEM), a Zune port would be much integrated to OS4 from fact it would be full and not OEM, and because you can have full power on Zune sources...
This is the point I am trying to make, it WONT be integrateed into the system anymore than MUI is now, purely because OS4 doesn't use it, so it won't use Zune. If it would be adopted in favour of MUI, it would be just the same as the current situation. [/quote]
Quote:
If Zune/MUI appears now better than BOOPSI/Reaction in many situation, most of modern ones, I don't understand why don't use this opportunity during waiting of a new modern GUI framework
Again, the resources required to change every OS component that currently uses BOOPSI to using MUI/Zune would be too much. That time would be better spent on other things, like writing the new prefferable GUI toolkit...
Quote:
To use a full Zune version instead of a OEM MUI version could give to OS4 only benefits:
1) benefits for users = complete package without any key; 2) benefits for 3rd part devs = an alternative and under development GUI framework to use instead of BOOPSI/Reaction (under development because you could be free to add features without violating any kind of contract, like if I've understand, it happens now with MUI OEM on OS4); 3) benefits for OS4 team = you don't have to ask permission to modify Zune as you like, and you have full power over its sources...;
I fail to see how spending an absolute age converting OS4 to use Zune would be in any way an advantage over what is available now. Doing away with the OEM version would be handy, but anyone that used MUI to any extent probably already has a key anyway. Bear in mind MUI is a contribution, present purely to allow third party applications to run without the need to download the MUI package first. None of the OS uses it (AHI prefs uses it, yes, but that too is a contribution, not a component)
So, I see the bottom line as: The effort expended in this thread talking about MUI/Zune could already have been better spent, and the end result is still the same - highly unlikely that Zune will be adopted, even as a contribution, let alone the OS actually using it.
Bear in mind MUI is a contribution, present purely to allow third party applications to run without the need to download the MUI package first. None of the OS uses it (AHI prefs uses it, yes, but that too is a contribution, not a component)
It's just curious that, a part of CodeBench (AWeb is old to be considered) I don't see any other kind of big new software which uses Reaction (joerg himself tells us its OWB port is using GadTools, so...)... It's just curious that in this thread Reaction "lovers"(;D) speak about external classes as the first evil thing of MUI when even Codebench to work uses an external class (richeditor.gadget).
If software makes a platform (and this is true) I find very strange to give an OEM version of main GUI framework used by 90% of all Amiga software. If you prefer don't believe MUI as an essential component because OS4 core parts don't use it you're free to believe this, but if without it you can't take your mails, goes into any kind of chat, see webcameras, etc... then this framework can considered an important part of your OS, because without it you can only open drawers and few other things...
Your idea of MUI as contrib for OS4 would work if when OS4 was distribuited to users, all new software were written using Reaction, but this was not happened.
To make a comparison of the current Amiga situation and with your idea (which sees MUI worse then reaction): it's as if on MacOS, with OSX version, devs had worked using Carbon (MUI) instead of using Cocoa (Reaction) for new applications. It would be an anomal situation...it means Cocoa was not like to devs and so it should be change to offered better alternatives to Carbon, or, if this was not possible, it would be better to enhance Carbon. And in this situation Carbon is not OEM, but full. This is another important thing on which to think. Why a dev should choose an OEM framework for a new software instead of a fully supported GUI framework like Reaction? This is just happened on OS4...
With the current Amiga situation and with current choice of 3rd part devs (which does the real Amiga platform from Commodore to now with their software) it would be at least to give to user a full version of MUI/Zune...
Quote:
So, I see the bottom line as: The effort expended in this thread talking about MUI/Zune could already have been better spent, and the end result is still the same - highly unlikely that Zune will be adopted, even as a contribution, let alone the OS actually using it.
It's a forum, we're discussing about interesting things IMO :)
If software makes a platform (and this is true) I find very strange to give an OEM version of main GUI framework used by 90% of all Amiga software.
MUI was never part of AmigaOS, it was always a 3rd party GUI toolkit. The only reason an OEM version of MUI had to be included in AmigaOS 4.x is that a part of AmigaOS 4.x, the IBrowse OEM version, needs it. If AWeb would have to been used instead of IBrowse, like in AmigaOS 3.5 and 3.9, MUI wouldn't have been required by anything in AmigaOS 4.x and wouldn't have been included.
So with OWB do you believe it will be removed from OS4.x? Ahhh, it's true, now even Yam is becomes an important OS4.x 3rd part software included into Utilities/, so...
So with OWB do you believe it will be removed from OS4.x?
IBrowse? No. It will take several years until OWB will have enough features to replace a complete browser like AWeb or IBrowse, even if they don't support CSS, etc.
Quote:
Ahhh, it's true, now even Yam is becomes an important OS4.x 3rd part software included into Utilities/, so...
Unlike the OEM IBrowse YAM isn't a part of AmigaOS, and IIRC it wasn't included in AmigaOS 4.0 yet. If MUI wouldn't have been required for IBrowse a demo version of MUI could have been used for the YAM version included as contribution in AmigaOS 4.1.
It's just curious that, a part of CodeBench (AWeb is old to be considered) I don't see any other kind of big new software which uses Reaction (joerg himself tells us its OWB port is using GadTools, so...)...
I don't see why AWeb is too old to be considered - if that is, then so is IBrowse, and most other Amiga software.
NetSurf and TuneNet both use Reaction, but it kind of depends on how you are defining "big".
There aren't really any big new Amiga applications since a long time. Most of them are updates of old ones, or ports with a new GUI attached. CodeBench is an exception.
to reply to you and Chris, all program bigger than a prefs/utilities included into system (except things like AmiPDF or similar...) can be considered on Amiga "big"
pftp? yes, it is a new one.... but modern concept of UI? no it isn't for sure, when I've used it I feel like I was on GEM2, sorry
I would introduce you a couples of interesting articles about modern UI:
Before to write a new software we (you?I've just done...) should read at least these... An integration of these articles with Amiga User Interface Style Guide could be good kind of know-how before to write new software...
Edited by ShInKurO on 2009/2/15 8:15:32 Edited by ShInKurO on 2009/2/15 8:16:42 Edited by ShInKurO on 2009/2/15 8:17:29 Edited by ShInKurO on 2009/2/15 8:22:43
> It takes me back to the days of BBSs when people thought > offline readers were brilliant
I DID rely on an Offline Reader and did think it was brilliant. Remember BBSs were before the days of fully on boraband and every minute spent online ran up huge phine bills. Especially as thge BBS I tended to use was based in London at the opposite end of the country so it was not cheap to dial. It was even quite expensive *with* the OLR but would have been prohibitively so without one.
Offline Readers were not only but essential.
Likewise until broadband reached this part of the world it was prudent to use Arexx scripts with YAM to put the Miggy online when collecting email and take it offline immediately after.
Ah those were the days - NOT.
The OLR was not MUI based either nor Reaction based (I doubt Reaction existed then even as ClassAct) but used well written gadtools which was more than adequate for what it did.
I still prefer things written with MUI though, it is just personal choice.
I already see how this thread could evolve... perhaps better moved into "to hot to handle"
My thoughts are that Reaction should be preferred for all new developments on AmigaOS4 as it is a part of the system supplied, supported and developed by Hyperion. That MUI is currently available is a bonus for older applications and some ports.
We don't know if MUI will see further development (on OS4+) or even if it will be supplied with the OS in future updates.
Just my thoughts and not anything to do with technical matters or what is best.
My thoughts are that Reaction should be preferred for all new developments on AmigaOS4 as it is a part of the system supplied, supported and developed by Hyperion. That MUI is currently available is a bonus for older applications and some ports.
Quote:
Just my thoughts and not anything to do with technical matters or what is best.
In fact, it should be, but it isn't (wookiechat, sabreMSN, Epistula, NoWinED, MUIBase, netmon, AmiReplace,MAutodoc, ZoomIT, AutoDocReader, etc...)...so why new 3rd part developers (even OS4 3rd part devs!) prefer to write new softwares with MUI instead of Reaction even if MUI is OEM while Reaction is full? Reply yourself to this question and you will have complete vision of situation of Reaction and why here we're discussing, this is enough intuitive even without any technical matters
I have written program for both MUI and ReAction and I like to say that MUI is simpler and more comfortable to write for. ReAction have a few advantages but MUI has more. My main reason when choosing MUI over ReAction for new OS4 programs is that I like to stay portable and using ReAction isn't portable - it only exists on OS4 and possibly OS3.5/9. MUI exists on all platforms.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Troels wrote: We don't know if MUI will see further development (on OS4+) or even if it will be supplied with the OS in future updates.
I could say the same about AmigaOS4.1, but MUI has easy 3rd party class support: just look at AmigaOS3.x MUI, there are dozens of classes developed by third party coders.
The difference is that it's easy to create new MUI custom classes.
Easy, but still more work than creating new standard BOOPSI custom classes. There are 2 more reasons why I'll never do anything with MUI on AmigaOS 4.x: - To use MUI in AmigaOS 4.x software you first have to create an AmigaOS 4.x MUI SDK yourself, the existing one can only be used for compiling old AmigaOS 3.x sources (it only works when using -D__USE_INLINE__). - To create MUI custom classes you have to register MUI.
Quote:
E.g. check out AROS OWB port with custom tab class that allows adding/removing tabs
That's just another reason against using MUI or Zune: To be able to use tabs he had to create a new tab class, the ones of MUI and Zune don't support dynamically adding and removing tabs and therefore couldn't be used for OWB. The AmigaOS 4.1 clicktab.gadget supports dynamically adding and removing tabs and I didn't have to implement my own one.
There are 2 more reasons why I'll never do anything with MUI on AmigaOS 4.x: - To use MUI in AmigaOS 4.x software you first have to create an AmigaOS 4.x MUI SDK yourself, the existing one can only be used for compiling old AmigaOS 3.x sources (it only works when using -D__USE_INLINE__).
? As you can see in these sources I don't use __USE_INLINE__ and it works...:
P.S.: do you know a way to know the actual state of CD-Rom with trackdisk.device commands?
Quote:
- To create MUI custom classes you have to register MUI.
It's not true anymore, in fact you can read Zune documentation to take what values have to use with TAG_USER to create proper MUI custom classes. In any case I know stunzi gives you a sicure value for your attributes and methods if you want even if you are not registered... In other words: "you can ask and they help you..."
Quote:
That's just another reason against using MUI or Zune: To be able to use tabs he had to create a new tab class, the ones of MUI and Zune don't support dynamically adding and removing tabs and therefore couldn't be used for OWB. The AmigaOS 4.1 clicktab.gadget supports dynamically adding and removing tabs and I didn't have to implement my own one.
Again, it's a problem of MUI3.x, on MUI4 you can dinamically adding and removing tabs. In any case clicktab.gadget is not used on OS4.0 so I suppose this feature is reserved only for OS4.1 users, kicking off all AmigaOS4.0 users (classic users included). So even an external Reaction class would be preferred in this case.... but if you have to create an external class even on Reaction to give support to all OS4.x users, then you can use MUI
In any case, custom class of OWB AROS is now avaiable, so it's possible to use it...
One thing going for ReAction is that there is no MUI4 on OS4 (yet, and i doubt there ever will be), and MUI3.9 is pretty much stagnating. Sure, there are updates, but its mostly bugfixes.
Please open Sys:MUI/Docs/ChangeLog-OS4 and read this:
2005-12-17 Jens Langner <...>
* final OS4 relevant housekeeping of the MUI 3.9 sources as we will concentrate on porting the MUI4 sources.
In any case, IMO who want use Reaction will always use Reaction, it's a choose...but who want use MUI should have latest MUI to use it on OS4, I'm not the only one who request MUI(4) on OS4, MUI is so request even by other many 3th parts devs... In any case for my dev POV I will always use MUI3.8 API because I write portable sw... but if I want write a software only for OS4 and MOS I'd like to use MUI4 API...
And it was just figure out as MUI4 is useful to port MorphOS software to OS4 in easy way...
In other word, to have MUI4 on OS4 give only advantages for users and 3th parts devs...
DiscreetFX?has just write to Stephan Stunz:
Quote:
We offered to buy Stefan Stuntz Amiga OS 4.1 for his PegII but he said Hyperion should send it to him. The new Aladdin 4D uses MUI and we don't like the current situation of MUI 4.0 being on MorphOS but not OS 4.1.
So we want know if this AmigaOS4.1 for Pegasos is just sent to stunzi...
In any case, custom class of OWB AROS is now avaiable, so it's possible to use it...
It can't be used in the AmigaOS OWB since it's a Zune class, not an AmigaOS 3.5+ BOOPSI class. If someone removes the Zune dependencies and addds the missing BOOPSI methods and attributes I might use it for OWB, but I wont port it myself.
If you want an OWB with a MUI or a Zune GUI you have to create it yourself, or port Zune and the AROS OWB to AmigaOS 4.x.
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
An integration of these articles with Amiga User Interface Style Guide could be good kind of know-how before to write new software...
