Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
59 user(s) are online (40 user(s) are browsing Forums)

Members: 1
Guests: 58

AmigaOldskooler, more...

Headlines

Forum Index


Board index » All Posts (ShInKurO)




Re: Proposal to make Zune MUI4 compatible (Bounty)
Just popping in
Just popping in


@kas1e

I don't think, we should open it on http://www.power2people.org/

Go to top


Proposal to make Zune MUI4 compatible (Bounty)
Just popping in
Just popping in


MUI is perhaps the only valid API for UI which identify the Amiga out of Amiga community: who has used AmigaOS between 1993 and 2001 (when Amiga community was very powerful and was able to mantain in life our platform) knows all most useful Amiga applications were written in MUI and old developers remember how was fun and easy to write a program with MUI.

Who has left Amiga community was inspired by MUI experience to written many projects which are used in other platforms. When OS3.5 was annunced without MUI many developers left Amiga community because for them MUI was an important part of the Amiga experience.

So we can state MUI is an historical piece of AmigaOS like IPC ARexx and Datatypes concepts.

MUI APIs are avaiable in all Amiga flavours in different forms and versions:

OS3 : MUI3.8
OS4 : MUI3.9
Mos : MUI4
AROS: Zune (MUI3.8 compatible)

However, excluding MorphOS, MUI is a shareware framework, which in form of not register software doesn't give to user some of its features (extreme personalization of UI).

Zune is an open source implementation of MUI which is included in AROS project, it is compatible with MUI3.8 APIs and it has some features which are missed on MUI3.8. In the latest years Zune was ported from AROS to AmigaOS3, and so the only MUI registered features and Zune modern features can be used on OS3 for free.
Zune is even ready to be ported on OS4.

Many OS4/AROS/OS3 users are interested to have software like OWB-MOS and Ambient on their systems, but these software use new API of MUI4, so the better way to have these software on OS4/AROS/OS3 would be to have MUI4 on these systems.
However MUI author seems not to be interested to do a port of his latest framework version to OS4/AROS/OS3, so only MorphOS users can use these software and only MorphOS developers can use MUI4 for their software.

We want create a bounty to make Zune MUI4 compatible. In a similar form Zune can give to their users software like OWB-MorphOS and Ambient with few work on system where Zune is avaiable.
To third parts developers a Zune MUI4 compatible would give an easy way to write their software in a easy portable way between different Amiga flavours without too much work because they could use a only powerful framework API instead to workaround different behaviours of MUI3.8/MUI3.9/Zune.

So we have a first draft of a bounty "To make Zune MUI4 compatible":

FIRST STEP
Quote:

@saimon69
Debug current Zune codebase and,where possible, improve existing MUI 3.x
compatibility adding missing functions and fixing current broken features,

Quote:

@Ball000
1. Port Fab1's OWB. Seems it mainly means "Implement in Zune MUI4 functions needed to compile Fab1's OWB" (of course the port itself would need some other work (improve CAIRO?), so this bounty can't be only Zune-related);

Quote:

@Fab
That would indeed be the most practical way. I don't think i'd like to have tons of "duplicated" code in OWB just because previous MUI versions didn't support methods for construction/display and co, for instance.



SECOND STEP
Quote:

@Ball000
2. Implement MUI4 functions needed to compile Ambient (but yet again, the port of Ambient will need other works to be done, especially system functions, as Ambient relies on some specific improvements of MorphOS);

Quote:

@bernd_afa
Sebastian Bauer have zune port to run on OS4.there are some os4 ifdefs in.

Quote:

@ShInKurO
This Zune enhancement would be very good even for an eventual port of Ambient on AROS/OS3/OS4 and to make Ambient in this way what DirectoryOpus Magellan was for AmigaOS some years ago.


THIRD STEP
Quote:

@Ball000
3. Implement remaining functions of MUI4 in Zune.


Other discussions about this topic are:
http://amigaworld.net/modules/newbb/v ... p?topic_id=32260&forum=15
http://aros-exec.org/modules/newbb/vi ... t_id=45752#forumpost45752

Go to top


Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


@trixie

Quote:

Tags should describe object properties, not invoke function calls - that's what methods are for. So the introduction of the child removing method was the right step, in line with OOP principles.


Uhm...

Quote:

if(LayoutBase->lib_Version>=53)
{
IIntuition->IDoMethod((Object *)mommy, LM_REMOVECHILD, inst->Win, ubrow->buttons[j], TAG_DONE);
}
else // Use fallback function. Note, this function may deadlock
{
IIntuition->RefreshSetGadgetAttrs(mommy, NULL, NULL, LAYOUT_RemoveChild, ubrow->buttons[j], TAG_DONE);
}


I believe LM is for LayoutMethod, so here is used a method which is called on object mommy and take a window and the object to remove (a button).

On MUI you does:

Quote:

DoMethod(group, MUIM_Group_InitChange);
DoMethod(group, OM_REMMEMBER, button);
DoMethod(group, MUIM_Group_ExitChange);


You tell to MUI you are doing a change(s) into a group and then you make your changes, in this case you remove a button from a group with BOOPSI method OM_REMMEMBER.

From programming POV is better the new LM_REMOVECHILD (from this little example code) because system takes care about the state of objects, while in MUI way user have to take care of state of object to change with IntiChange/ExitChange.

Go to top


Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


@orgin

Quote:

Code example for anyone interested:


Good to know, thanks

Go to top


Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


@madmonkey

Quote:

It is possible but you have to subclass the objects and add the support yourself. Which leads back to the problem that some objects cannot be subclassed due to the lack of exposed properties.


Uhm, I haven't here my A1, I'm curiuos about this aspect of d&d, can you show me how Reaction API should work with d&d? Yes, definitely without subclassing life is very hard for Reaction programmers

Quote:

This is what is so silly and messy with Reaction the old methods should have been fixed not introduce new methods.


This is not always good, because it could be broke working applications, so with a fix they broke something else. This is the usual problem of an old broken API well know by programmers: they write their programs workaround problems, so their software become dependents by that bug. If a mantainer of that module fix the problem, all applications which workaround it will not work anymore.
Old methods are mantained for compatibility, it's a good thing, BUT documentation MUST BE CLEAR, "OBSOLETE, DO NOT USE IT", or something similar
So the real problem is lack of documentation at this point...

@ abalaban
Quote:

So you felt the need to start one


I don't start any flame, only minded discussions ;-P

Quote:

Please no, I don't think users want to carry on their HD huge development materials for which they don't have a slight need of.


Ehm, you should speak for you ("in your opinon"): I would want huge development materials on my HD, without an huge (and ordered) documentation even a wonderful API become bad
You give me a good book about Reaction from beginning to all new APIs of OS4 and I will program you in Reaction (sure, I want first a good menu class and subclassing support for all classes and d&d for all classes of course)

Quote:

IMHO autodocs are fine (the principle, see it has been adopted by almost every documentation system : javadoc, doc++, etc.) they just need a serious refreshment (that already started in latest SDK thanks to Steven Solie IIRC) and they should be kept up to date when the code is modified that's all. We also need more general documentation in order to understand the general concepts under such or such part (BOOPSI is probably the one needing the most explanation, but (good) device writing is another one for example).


Autodocs are fine for who knows where he must use his hands... and these people are few... for beginners (and in this Amiga situation we are all beginners, and even a good programmer from another platform would be a beginner if he would go into Amiga dev world) the only good thing would be an huge upgrade of RKRM Libraries, Devices and Style guide volumes.

Go to top


Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


@samwel

Quote:

What is missing from ReAction?
What's wrong with the ReAction implmentation?
Is it possible to fix without a total rewrite?


One of thing nobody has mentioned is Reaction notification system, this is few intuitive and very poor than MUI's one. If we said true, MUI notification system is what makes MUI intuitive, and gives to it a particular "Amiga" way to implement notification system into an UI toolkit. In fact even if other UI toolkits are more advanced than Reaction/MUI in many aspects, MUI notification system appears always more intuitive than other ones and enough powerful to use it into modern applications implementations.
MUI notification mechanism is an "Amiga way" to do something and it would be nice if Reaction or whatever new UI will come on OS4 would implement it.

Quote:

In another thread I read about the limiting menu system
of Amiga OS, which I gathered Intuition handles.
Is this fixable with a new ReAction menu class?


sure, if someone would implement it/them

Quote:

Also what is generally missing or wrong in AmigaOS4 GUI
that we (the users aswell as developers) want changed?


A new, modern (and if we can do, innovative) file manager/Desktop.

Go to top


Re: ReAction, what is missing to make it a good GUI?
Just popping in
Just popping in


@madmonkey

Quote:

Reaction is a v difficult system to work with. It's fine for a simple GUI but trying to do anything complex with it is a nightmare.


Strange, I don't see any flame war after this line, perhaps amigans have finally seen how lack Reaction is? :)

Quote:

1) Dynamic GUI changes cause lock ups. Yes I know there have been some fixes in 4.1 but these lockups can still occur


All modern UIs are based on these dynamic changes, so this is a BIG lack, as I said in past...

Quote:

2) Drag n drop built into objects. Drag and drop is possible but each object requires subclassing atm.


Nope, it's not possible at all. What you define with d&d is Workbench AppWindow support, but in Reaction you can't drag a Reaction object and drop it into another one or into Workbench. This is the reason Filer has no d&d, and it will never have until listbrowser.gadget (and so Reaction) will support a proper D&D API...

Quote:

3) It is impossible to subclass some objects due to the lack of exposed properties so effectively you have to write your own gadgets from scratch, increasing development time considerably.


This another very BIG Reacton flaw, without subclassing a Reaction class you can't build a proper big project without to become crazy to develop and MANTAIN it. All modern UI toolkits permit subclassing their classes.

Quote:

Certain OS developers have the opinion that you should not be subclassing system gadgets. Why? No idea seems pretty insane to me


Because they live into '80 ages, it's enouch clear to me

Quote:

4) Some objects do not support the standard gadget tags but instead implement their own tag that does the same thing. Trial and error makes development time v slow.


Sad thing which is joined with subclassing problem...

Quote:

5) Documentation is poor. I would like to see self documentating objects i.e. standard properties that return list of all supported tags, descriptions etc.


nope. MUI documentation is very poor, Reaction documentation is not existant... ;->

Quote:

Oh I could go on forever about how bad Reaction is when compared to other GUI systems.


I could go on forever about the fact without MUI I wouldn't have programming on The Amiga at all because MUI is more similar to modern programming styles than Reaction... ;->

Go to top


Re: Firefox coming to OS4.1 !!!
Just popping in
Just popping in


@tfrieden

I've asked you that because I'd like to know if I would develop a XULRunner project (without to use any native feature of dev platform) what chances I could have to see my project to be execured on OS4...
I search for days what modules are included into Mozilla framework which aren't included in Firefox, bet they have written only there are modules not used by firefox, without to tell us what are them

Go to top


Re: Firefox coming to OS4.1 !!!
Just popping in
Just popping in


@Rogue

Do you think you will port even these things after to have finalized first porting of ff?

Go to top


Re: Firefox coming to OS4.1 !!!
Just popping in
Just popping in


@Rogue

Quote:

The Widget part isn't complete yet. There are a few things to do still (for example, popup windows that move with their parent). Networking had its share of problems too, like I pointed out (gethostbyname not being reentrant), we still have a while to go.


I've seen XULRunner screenshot, have you planned to port all XPCOM modules and so all Mozilla Framework? I hope We can write many modern applications with Mozilla Framework and to gain other applications just commons on other platforms

Go to top


Re: Firefox coming to OS4.1 !!!
Just popping in
Just popping in


@Rogue

Quote:

The presence of close buttons on the tab depends on the theme used. This theme doesn't have any. We hope to make a more Amiga-specific theme at one point (if we ever figure out how that works ;))


Eheh
I want notice all XUL applications have this "totally skinnable" feature, so...

Go to top


Just popping in
Just popping in


@abalaban

Quote:

We already loose Detlef W?rkner (tetiSoft) in early 2008 who was working on the locale part of the OS


What is happened to TetiSoft????

Go to top


Re: Migration to OS4 Hooks
Just popping in
Just popping in


@Rigo

I find SDI headers simpler in sintax for hook than each "native" solution (OS3, OS4, MOS and AROS), so it's a good start point for which wants convert/port/begin.

Go to top


static libjpeg, libpng, libz on OS4 SDK?
Just popping in
Just popping in


Hi,
into my actual SDK installation I don't found libjpeg.a, libpng.a and libz.a, so I've copied them from SDK v52, but I've this problems with libpng:

/SDK/local/newlib/lib/libpng.a(png.o): In function `png_reset_crc':
png.c:(.text+0x248): undefined reference to `crc32'
/SDK/local/newlib/lib/libpng.a(png.o): In function `png_calculate_crc':
png.c:(.text+0x298): undefined reference to `crc32'
/SDK/local/newlib/lib/libpng.a(png.o): In function `png_reset_zstream':
png.c:(.text+0xd70): undefined reference to `inflateReset'
/SDK/local/newlib/lib/libpng.a(pngwrite.o): In function `png_write_flush':
pngwrite.c:(.text+0x1dcc): undefined reference to `deflate'
/SDK/local/newlib/lib/libpng.a(pngwrite.o): In function `png_write_destroy':
pngwrite.c:(.text+0x1eac): undefined reference to `deflateEnd'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_text_compress':
pngwutil.c:(.text+0x3a0): undefined reference to `deflate'
pngwutil.c:(.text+0x488): undefined reference to `deflate'
pngwutil.c:(.text+0x548): undefined reference to `deflate'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_write_IHDR':
pngwutil.c:(.text+0x938): undefined reference to `deflateInit2_'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_write_iCCP':
pngwutil.c:(.text+0x34b8): undefined reference to `deflateReset'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_write_zTXt':
pngwutil.c:(.text+0x3b24): undefined reference to `deflateReset'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_write_finish_row':
pngwutil.c:(.text+0x4b94): undefined reference to `deflate'
pngwutil.c:(.text+0x4cb8): undefined reference to `deflate'
pngwutil.c:(.text+0x50cc): undefined reference to `deflateReset'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_write_filtered_row':
pngwutil.c:(.text+0x54ec): undefined reference to `deflate'
/SDK/local/newlib/lib/libpng.a(pngwutil.o): In function `png_write_find_filter':
pngwutil.c:(.text+0x6254): undefined reference to `deflate'

Any ideas?

Go to top


Re: An open discussion on where we go from here
Just popping in
Just popping in


@DaveP

Quote:

In the middle of this depressing situation we have a technology divergence going on. Let us consider the three or four main players:

1.Amiga OS4.x
2.AROS
3.Amiga OS3.x
4.MorphOS

If you develop for Amiga OS3.x you have a reasonably good chance of being able to port it to AROS without much modification, and AmigaOS4.x with some modification. Obviously, depending on what you do. It is a laughable thought that you could develop for Amiga OS3.x plus RTG and then rely on the emulation layer of Amiga OS4.x to execute it, presumably the same applies to MorphOS.

The ideal situation would be some convergence going on, perhaps a standards group overseeing not just a set of guidelines for developers of device drivers, portability layers and application software to help them avoid making expensive (in terms of time spent) implementation decisions.


There are some standards de facto you use if you want to be compatible with all Amiga flavours, they are MUI, AHI, CGX. It's so difficult to understand?

Quote:

Ideally you could write for one, and recompile for all others with some idea that it was going to work. For the developer this would be a boon, for the users, well it would allow them real freedom of choice when selecting their Amiga-like distribution. For the OS developers, it would mean some real competition. Having a standards group would not mean an end to innovation. Like anywhere, an idea could be tried out first on MorphOS, giving that the advantage temporarily, and if it was successful the demands of users on the other platforms would help it race through the standards group and get implemented on the other distributions.

Of course, there are going to be many out there that will refuse to port using applications as advocacy for a given distribution. Well, so what? Given enough time and developers and most importantly end users for developers to sell (or get kudos from) to competitive applications would appear.

I urge technical co-operation between the development groups. Put personal vendettas aside, and work together on a new AmigaOS API standard that all can share in common.


You can't see any kind of cooperation from each side, each OS dev group is interested to its OS only. You can see some cooperation from third part devs, and these cooperations have just pruduced things like SDI headers and common framework files to create libraries and mui classes portable (you find it into MCC classes opensources).
The only thing you can't have in common are drivers, you can't write a portable driver. But for normal development you can develop whatever you want following Amiga standards de facto API... the only reason some software were not developed on the Amiga was lack of a fast hardware, because with MUI+AHI+CGX you can develop much more of you have seen during these years. If you want use some OS specific features you can use conditional code, it's simpler than what you believe.
There are many software actually follow Amiga API standards de facto, they are Yam, SimpleMail, WookieChat, SabreMSN, NoWinED, NewsCoaster, AutoDocReader, etc...
So the only difficulties I see with Portable Amiga Programming is into mind of some developer. If you have in mind to write only OS4 software of course you can choose to use API like Reaction, Picasso96, etc... but it's only an your choose, not a tecnical one.

If MUI3.8 API would be so obsolete then Zune which is very young and with some missing features of MUI3.8 wouldn't give any chance to build for AROS an OWB version with dynamic adding/removing of tab pages.
On MUI4 there is a builtin class to make this, on AROS OWB developer has implemented a custom class which is opensource and soon or later will arrive on MUI3.x... and so all MUI flavours will have a common opensource class for these kind of things, like it's happened with TextEditor, BetterString, NList, TheBar... which are currently default installed on OS4 and so a dev has not worry an user has to install these classes.

What you miss yet to write from scrratch an Amiga Portable application? A guide? Here:

http://code.google.com/p/guidetoamigacompatibleprogramming/

Go to top


Re: An open discussion on where we go from here
Just popping in
Just popping in


@Rigo
Quote:

While I salute your idea of a common API for the Amiga-alike platforms, that is going to be restrictively prohibitive. The biggest problem is going to be in the user interface. One uses MUI, one uses a MUI clone and the other, Reaction. To build a common API (wrapper) for those would mean leaving out a lot of functionlity from each GUI system. I have personally implemented a few modern features within Reaction that is not available in MUI, and I know that works the other way around too. I doubt the AROS MUI clone has all the features of MUI 4 either.


Without to deny obvious missing features from MUI4 to MUI3.x and Zune, you can always obtain more modern UI using MUI3.8 APIs instead of use Reaction for OS4 today and you will obtain an application which goes on each Amiga flavour. One between all features which actually Reaction misses is Drag&Drop between UI objects like gadgets. You can't implement a Toolbar configuration like on Firefox with Reaction, while you can with MUI3.8, and of course it will work on Zune:

Resized Image

And this is olny one of many features which MUI3.8 API gives to a dev and which are missing on Reaction OS4 today...

Quote:

This would lead to a common API which misses a lot of the latest features, and would only allow access to any common functions between the systems.


If you want use a particular feature of a specific AmigaOS flavour, for example AmiDock support, resource tracking etc of OS4 you can always use #ifdef __amigaos4__ #edif....

Go to top


Re: how to disable Grim/DSI window ?
Just popping in
Just popping in


@Mrodfr

MemGuard+SashimiPPC, download from OS4Depot...

Go to top


Re: OWB 3.15
Just popping in
Just popping in


@joerg

Quote:

That's impossible since the MorphOS port of OWB is not open source. But even if the sources would be available they would be just as useless as the AROS ones, about 90% of the code for a download manager is GUI related and the MorphOS one uses MUI4.


Ehm, really MorphOS OWB and AROS OWB share almost the same code for download manager, or I had understand in this way...

Go to top


Re: Would a UI library be useful ?
Just popping in
Just popping in


@DaveP

Please open Microsoft Word on MacOSX and tell me if first menu which you read is the same of first menu which you have on Windows. First menu of Windows is the second one into OSX version, and reason is UI style guide respect...

Go to top


Re: Would a UI library be useful ?
Just popping in
Just popping in


@DaveP
Quote:

Are you saying that I can change all the menu options in an MUI application, the order of menus, and even what menu items are called in a MUI application from the prefs panel?


No I mean menu bar position can be into window program like on Windows.
Btw you can easely implement something of this with MUI, and control it from prefs of your program. In any case it wouldn't be good because Amiga Interface Style Guide tells you how should be the order of standard menu like "File", "Edit" and "Prefs" menus so you would have a not standard application, even if you could leave this choice to user...

Go to top



TopTop
(1) 2 3 4 ... 6 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project