@abalaban

why did you stop working on it?

_________________
AOS4 Betatester, Peg2, G4@1ghz, Radeon 9250 256mb, 1gb RAM.

http://www.asciiarena.com
http://www.uprough.net

@spotUP

I don't know, I would say :
"Too much things I wanted to work on, too less spare time" and also not so many interest in the community at that time.
Also one of my main weakness being that I want to do too much at the same time (and not having enough time to do all of them). For example currently I should :
- release an updated OpenURL version that is on my HD since months,
- release an updated ISpell version I worked on last month,
- finish to update to latest sources (3.5.3) the SQLite port we did with Steffen Gutmann ,
- track changes to MUIbase (I'm the OS4 porter),
- finish (and test) a code patch I wrote for Jabberwocky,
- do some french translations (YAM, MUIbase, Jabberwocky, and many more...),
- update SWFPlayer (mainly I want to create a flash.library),
- work on dozen other things I do for fun when I'm borred by all those serious things above

I might help a bit for a wxWidget port but I certainly can't do it myself alone unless if I can clone myself

EDIT: Oh I almost forgot :
- test and eventualy release the port of bison 2.1 I have on my HD,
- test and eventualy release the port of libexif I did,
- send a debug version of FTPMount to Elwood to help tracking a bug,
- finish my C++ implementation GuitarPro 4 reading library (this one being part of the 'for fun things'),
- ...

In fact re-reading my post I'm completely mad

Last edited by abalaban on 14-Dec-2007 at 10:00 AM.

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@Hans

Quote:

Hans wrote: @Heinz Are their any cross-platform GUI design tools? wx-DevC++ is windows only. I'll really have to have a closer look at wxWidgets now. Hans

This one:

http://www.codeblocks.org/

I never used it, so I am not sure if it has a GUI Designer, but it looks good.

BTW it is written with wxWidgets ...

@Hans

Quote:

So, is there any interest in resurrecting this project?

Yes, I think it is a very interesting project, and although my time is limited, I would like to help out.

Is this port supposed to wrap around the native widgets, or around the themable engine? The latter could be easier to port I suppose, especially if there are supposed to be Classic, OS 4 and MorphOS versions, although of course MUI could be used on these.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Heinz

Quote:

I never used it, so I am not sure if it has a GUI Designer, but it looks good.

It also has a GUI designer. I used it before, as a matter of fact, I used the IDE (not the GUI designer obviously) to write the Installer for the Classic CD.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue

Quote:

Rogue wrote: @Hans Quote: So, is there any interest in resurrecting this project? Yes, I think it is a very interesting project, and although my time is limited, I would like to help out. Is this port supposed to wrap around the native widgets, or around the themable engine? The latter could be easier to port I suppose, especially if there are supposed to be Classic, OS 4 and MorphOS versions, although of course MUI could be used on these.

I have a very limited understanding of the source, but looks like it's mostly a wrapper around native widgets, and other parts of the OS. It also has a universal set of widgets that can be used to fill in those ones that an OS doesn't have. A wrapper for OS drawing calls (probably via a GInfo struct would be best) so that custom wxWidgets can also be made.

I have no idea how the themable engine works, but that could be another option. One advantage of using native widgets would be that you take advantage of intuition's way of doing things (e.g.., redrawing occurs in the intuition task, making everything feel more responsive).

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@DaveAE

BTW, if we had wxWidgets on Amiga OS, how likely would it be that Audio Evolution 5 gets an Amiga OS4 version? IIRC, version 4 has an OS4 version, but version 5 is currently Windows and Mac only.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Very likely.

_________________
Audio Evolution
http://www.audio-evolution.com

@Hans

Quote:

I have a very limited understanding of the source, but looks like it's mostly a wrapper around native widgets, and other parts of the OS. It also has a universal set of widgets that can be used to fill in those ones that an OS doesn't have. A wrapper for OS drawing calls (probably via a GInfo struct would be best) so that custom wxWidgets can also be made.

AFAIK (I had a look at it a while ago) there are two general directions, the "native" wrapper and wxUniversal, the themable version. I don't have any clue about how fast this is.

Quote:

I have no idea how the themable engine works, but that could be another option. One advantage of using native widgets would be that you take advantage of intuition's way of doing things (e.g.., redrawing occurs in the intuition task, making everything feel more responsive).

What I dislike about Intuition's way of doing things is how a crash in one gadget's code can kill the whole system. The next generation design therefore plans to move GUI rendering out of the application into a thread, which will be automatically created by the system once it starts doing any sort of GUI code.

The same could basically be done for wxUniversal.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Hans

if wxWidgets is ported does that meanwe can finally crunch Rosetta on Os4 ?

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

@Rogue

Quote:

Rogue wrote: @Hans Quote: I have a very limited understanding of the source, but looks like it's mostly a wrapper around native widgets, and other parts of the OS. It also has a universal set of widgets that can be used to fill in those ones that an OS doesn't have. A wrapper for OS drawing calls (probably via a GInfo struct would be best) so that custom wxWidgets can also be made. AFAIK (I had a look at it a while ago) there are two general directions, the "native" wrapper and wxUniversal, the themable version. I don't have any clue about how fast this is.

Oh, is that what you're talking about. I'd imagine that using wxUniversal would be the first step, even if you're using the native gadgets. It would be an intermediate step. The disadvantage of not using the native gadgets would be having to generate a new theme for every theme that the OS has, and having to switch the wxWidgets theme separately to match the OS's one. To be honest, wxWidgets using native GUI elements is why it interests me more than the other myriad of GUI toolkits. Bypassing that feature would make it worth less IMHO.

Quote:

What I dislike about Intuition's way of doing things is how a crash in one gadget's code can kill the whole system. The next generation design therefore plans to move GUI rendering out of the application into a thread, which will be automatically created by the system once it starts doing any sort of GUI code. The same could basically be done for wxUniversal.

True. That is a problem with intuition. However, it's much better than the application's own thread having to do the redraw, causing the GUI to freeze every time it does some major processing that takes a long time. Each app having its own intuition thread is the way forward.

Hans

Last edited by Hans on 14-Dec-2007 at 07:24 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

Bypassing that feature would make it worth less IMHO.

True, but on the other hand there are a few peculiarities of AmigaOS GUI generation that might not tie in too well with what other platforms use. Absolute positioning comes to mind, and although I think it is possible even with reaction, usually the wxWidget versions of widgets offer different or more functionality than Reaction (or evem MUI for the matter).

I don't know how wxWidget handles this, but usually I think if the native widget doesn't support the whole of the functionality, it is replaced by a self-rendered one.

Quote:

Each app having its own intuition thread is the way forward.

We've done that already with RAMLIB, by opening every library and device in its own thread. That takes away the catastrophic failures you get under OS 3.x when something crashes in the init code - you crash a single thread but the rest of the system still works. The pager works quite similar to this.

Actually, the handling of things inside the application was one of the things I disliked about MUI, in spite of its much superior functionality over Reaction. Of course you could do that yourself (use a thread for window management) but it adds additional overhead, and hardly anybody does it.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue

Quote:

Rogue wrote: @Hans Quote: Bypassing that feature would make it worth less IMHO. True, but on the other hand there are a few peculiarities of AmigaOS GUI generation that might not tie in too well with what other platforms use. Absolute positioning comes to mind, and although I think it is possible even with reaction, usually the wxWidget versions of widgets offer different or more functionality than Reaction (or evem MUI for the matter).

Ironically, GUIs on the Amiga always seem to resize nicely with the layout classes. One of my complaints about windows apps was that their GUI elements often didn't resize to match the font/language being used, resulting in cut off text.

Quote:

I don't know how wxWidget handles this, but usually I think if the native widget doesn't support the whole of the functionality, it is replaced by a self-rendered one.

That sounds about right.

Quote:

Actually, the handling of things inside the application was one of the things I disliked about MUI, in spite of its much superior functionality over Reaction. Of course you could do that yourself (use a thread for window management) but it adds additional overhead, and hardly anybody does it.

Considering that MUI is built on top of BOOSPI, I'm surprised that they did this. Actually, this could possibly be fixed in the MUI window or application class. I wouldn't know for sure as I've never programmed anything using MUI before.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@All

What about GTK-MUI ?

http://sourceforge.net/projects/gtk-mui/

_________________
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

GTK on windows is not a wrapper on windows. GTK apps don't look like native apps on windows, which defeats the purpose of the wrapper.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

As it happens I'm currently making some scripts using wxruby (on Windows). I tried tcl/tk at first but I didn't like how it looked and how the layout system worked. The BoxSizer in wxruby OTOH works very similar to ReAction's layout.gadget, which is nice, and it produces decent looking GUIs too.

Maybe when wxWidgets is ported to OS4, wxruby can be ported too (there is already a port of the ruby interpreter for OS4)?

Last edited by salass00 on 15-Dec-2007 at 12:54 PM.

@Hans

Quote:

Considering that MUI is built on top of BOOSPI, I'm surprised that they did this. Actually, this could possibly be fixed in the MUI window or application class. I wouldn't know for sure as I've never programmed anything using MUI before.

MUI is based on BOOPSI (SetAttrs(), DoMethod() and so on) but it is not based on existing BOOPSI classes.

In general BOOPSI has nothing to do with UI. It just happens to have some classes that compose window layout, was it ClassAct or MUI.

Quote:

Actually, this could possibly be fixed in the MUI window or application class.

There is nothing to fix. Running GUI in your own process is the right thing to do. It ensures that Amiga does not stop multitasking when gadget render is doing silly things.

If window refresh is problem then you can spawn separate thread for GUI easily (just call CreateNewProc() or use Process.mui class in MUI4). It is really piece of cake. For example Ambient runs its MUI GUI in a separate thread and DOS operations (copy, dirscan, icon layout...) are done in another. It is something what you must do with other GUI systems also (was it GadTools or ClassAct()) because silly DOS requesters could block your GUI completely.

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

@Hans

Quote:

GTK on windows is not a wrapper on windows. GTK apps don't look like native apps on windows, which defeats the purpose of the wrapper.

GTK-MUI is a wrapper -- it wraps GTK GUI into MUI GUI.

However for more complex applications it is not enough... Pango, ATK, GDK, glib, iconv... all kind of crap.

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

@itix

Quote:

Actually, this could possibly be fixed in the MUI window or application class.

Hmm... though, it could be easier if MUI spawned new thread for GUI rather than rely on application writers. Unfortunately BOOPSI was not designed for multithreading (in a way it is needed in MUI). Calling DoMethod() to MUI application from other thread is illegal except in few special cases...

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

@itix

Quote:

itix wrote: @Hans Quote: GTK on windows is not a wrapper on windows. GTK apps don't look like native apps on windows, which defeats the purpose of the wrapper. GTK-MUI is a wrapper -- it wraps GTK GUI into MUI GUI. However for more complex applications it is not enough... Pango, ATK, GDK, glib, iconv... all kind of crap.

Yes, GTK-MUI is a wrapper, but on other OSes it isn't (read what I wrote above). It's not designed to use the native widgets like wxWdigets is. My interest in wxWidgets is that I can write a GUI once and have it run on all target OSes without the usual problems of other cross-platform toolkits (such as things not matching the target OS's current theme, having to install 100MB+ of stuff).

Quote:

Quote: Actually, this could possibly be fixed in the MUI window or application class. Hmm... though, it could be easier if MUI spawned new thread for GUI rather than rely on application writers. Unfortunately BOOPSI was not designed for multithreading (in a way it is needed in MUI). Calling DoMethod() to MUI application from other thread is illegal except in few special cases...

I work under the assumption that programmers are lazy and don't like repeating things. Getting MUI to do this rather than leaving it up to application programmers is probably a good idea.

Hans

Last edited by Hans on 15-Dec-2007 at 03:47 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.