o1i's blog

2011-08-30T09:43:00.003+02:00

Janus-UAE v1.1 released

You will be able to download it from the
AROS archives/aminet, when the upload
is approved by the maintainers.

New features:

thanks to Krzysztof Smiechowicz, this is the first version, which can run AROS/m68k
added extended rom selection possibility in the gui
comes with AROS/m68k

There were some bug reports for v1.0, so this release
tries to fix them, mainly:

mouse pointer disappearance
If you move the mouse pointer outside a CLI window, the mouse pointer disappeared in coherent mode
gui drop box state was not saved/restored correctly
startup output is STDOUT again
you can remove a selected amiga rom key in the GUI
amirun might work again
fixed long time undetected memory trashing in the GUI
stop uae really stops uae and does not restart anymore sometimes
pressing quit stops emulation before it quits
double p96 id error requester does not appear anymore
1920x1200 amigaos resolution should work (again)
Load config did not really work

This is (nearly) the same version as released by Paolo with Icaros 1.3.1 (some debug output removed, "Internal Beta Version" messages removed).

2011-08-16T15:31:00.005+02:00

A cautious glimpse into the future

809-580: 'System:uae'
809-600: ROM loader..
809-620: Known ROM 'KS ROM v3.1 (A4000)' loaded
809-620: ROM loader end
809-620: memory init end
809-660: Building CPU table for configuration: 68000 prefetch 24-bit
809-700: 1879 CPU functions
809-700: Building CPU, 44316 opcodes (0 1 1)
809-700: CPU=68000, FPU=0, MMU=0, JIT=0.
809-700: CPUID level=5, Family=15, Model=4, Mask=3, Vendor=GenuineIntel [0]
809-700: JIT: Building Compiler function table
809-700: JIT: Supposedly 42101 compileable opcodes!
809-700: JIT: cache=0. b=1 w=1 l=1 fpu=1 nf=1 const=1 hard=0
809-800: Sound driver unavailable: Sound output disabled
809-800: ** RESTART **

2011-07-05T16:37:00.000+02:00

v1.1 beta test ..

2011-06-01T10:26:00.006+02:00

OT: Iron Maiden!

Just in case anybody is interested ;), I was at the Iron Maiden gig last night in Munich and it was GREAT!! Middle second row in front of the stage :))):

YouTube Source URL
And even if I hate all those people at concerts doing nothing else but trying to get as many pictures as they can, I could not resist to make one, too. (Well, my Nokia e71 is not really a good cam, so 4 of the 5 pics I took are unusable, but this one is quite ok):

Did I already mention, I was close ;)?

UP THE IRONS!

2011-04-29T08:42:00.003+02:00

Long way..

The wayback machine helped me finding, when the UAE bounty has been opened. Quite a while ago:

November 8, 2003. Two new bounties, #7 (UAE intergration) and #8 (CD ISO Improvements) have been added to the TeamAROS Bounty list.

Posted by: damocles on November 20, 2003

2011-04-26T15:47:00.002+02:00

Bounty completed!

Power2people agreed, that the bounty is completed, so I put a label v1.0 on Janus-UAE and released it at the AROS-archives. V1.0 is just a relabeled and recompiled v0.9, so there are no bug fixes/new features in there.

I already received the bounty money, which leaves me to thank all donators. The money will be spent for our next family vacation.

2011-03-09T14:44:00.003+01:00

Documentation

.. is always boring to do. I did a quick guide how to install AmigaOS3 with all required packages and configurations to get Coherency working in j-uae:

j-uae-guide.pdf

This took more time, than I thought, but it might be a starting point for some people.

2011-03-07T16:39:00.004+01:00

v0.9 released

janus-uae v0.9 hit the archives: janus-uae.i386.tar.gz

I finally found time to release this version, which was packed up a few days ago. It has the following fixes and new features compared to the 0.8 release:

GUI: configuration description is now displayed and can be changed in About tab
GUI: fixed p96 memory options, if 68000 is selected
GUI: JIT buffer size maximum changed, uses MB instead of bytes now (same as WinUAE)
GUI: ROM image names are now updated correctly, if you load a new config file
GUI: crash on exit after floppy image has been changed fixed
GUI: new CPU tab, which saves state correctly
Quit with window gadget does not crash juae any more
possible AmigaOS library close race condition fixed
removed all debug and symbols, stripped executable

2010-12-29T09:45:00.003+01:00

v0.8 released

janus-uae v0.8 hit the archives: janus-uae.i386.tar.gz

This is the first "stand alone" release since v0.3, all previous versions were "development snapshots" for distributions etc.

New compared to v0.7 is (at least):

minimum blit size is increased to 64 bits, whenever possible to avoid noveau slowdowns
window border gadgets are now done as AROS gadgets, no more ugly os3 window border gadgets, wherever possible
fixed a sound buffer overflow bug of e-uae
fixed mouse pointer hide bug
fixed many race conditions (I hope all of them)
fixed mouse pointer trails bug (use supplied winUAE rtg.library)
hotkey to show/hide GUI at any time
load/save different configurations
display current config file in about tab
removed ugly gtk menu
quit gui without running amigaos first should not crash anymore

This is still no v1.0, so I await your bug reports.

I hope, this version is stable enough, so I can relabel it as "v1.0" and claim the bounty. If not, well, there is still room for a v0.9 ;).

2010-12-27T13:58:00.003+01:00

p.bes special

p.bes: "What I need is JUAE able to load the configuration file, edit it with the gui, and then save it again with its name or another one choosen by the user."

I hope, this does the job:

You can now reload your current config, load a different one, save your current config and save it to another file name. Too late as a Christmas Gift, but anyways ;).

2010-12-20T16:54:00.001+01:00

v0.8 release candidate ?

The brave ones know, where to find beta versions ;).

2010-12-07T15:41:00.011+01:00

Money Matters (sometimes ..)

Money Matters was one of the software packages, which the bounty requires to run (http://www.power2people.org/projects/profile/1). So let's try to install it:

This is AROS with a small amigaOS workbench window:

Open the "floppy":

And launch the installer:

I have 2.7GB free on my partition, seems like this old installer can't deal with such sizes:

Ok, so we have to use an editor to fix it. We use the aos3 Jano Editor for that. (we could have used the native AROS version, too, of course):

AmigaOS Jano Editor (with AROS native border gadgets of course!):

Search for that "insufficient available space" message:

and where it is used:

Remove size check:

and try again:

and now it worked!

Money Matters in j-uae:

Money Matters runs on am amigaOS custom screen, so you will not get any fancy AROS menus, window frames or border gadgets, sorry. But of course you can launch it from wanderer or use the clipboard to exchange data with other AROS/aos3 programs.

Nevertheless, there is still this "big mystery bug", which I am unable to fix. I get random, rare crashes on aros-hosted on linux, but others get crashes much more often and faster. I just wanted to prove you, that j-uae *can* work, at least sometimes .. (to come back to the headline).

2010-11-02T16:12:00.002+01:00

Back to the classic

As my kids are now in an age (5 years), in which they start liking to play computer games, I decided to dig out my old a600. I bought that machine years ago, when I wanted to add a hard drive etc., but never had time for that.

I also got some discs and some joysticks (competition pro of course) with that machine. And they really enjoyed some of the games. They even think, that this "Amiga" is better than the Wii a friend of them has ;). Well, I think not everybody might agree with that.

But the downside is, that I don't have many games and not many for 5-years old at all. They are good at playing Barbarian, but "Prepare to die" might not be the right message for them. But they like the head kicking green guy ;).

So I decided to write some new discs, but how? My PC has no disc drive any more of course, the a600 has no network.. and I did not want to buy additional hardware.

So it was time to get my old a3000 from my parents house! I plugged it in and a gray screen appeared, "loading kickstart 2.x", but it failed. I had a SuperKicksStart Disc, but that seems to have r/w errors. Hmm..

I removed my cv64 and the serial card and .. it came up! I removed the battery before I stored it away, so I was lucky with that. Quit a nostalgic feeling, when I saw my old workbench. I have some backups of it, but only on DAT tapes, needless to say, I don't have any SCSI cards anymore to connect my drive to. After replugging the ZII and the ZIII card they worked again, so it must have been some dust there.

So I have another machine to write Amiga floppies. Still no network :(. I googled and found Cloanto's Amiga Explorer and liked the idea. I even found an old NULL-modem serial cable and wanted to plug it into my PC. Argl, it does not have a serial port either, something I thought it would have of course.

So I grabbed the old laptop of my wife, it luckily has a serial port and a ethernet port, and it was quite easy to see all drives and drive contents from the amiga on the laptop. Cool ey?

But it was really *difficult* to work with amigaOS for me. Quite scary. I have a BSC serial card, which should give higher speed than the amiga serial. But how do I find the right device? How do I test, which screen mode my TFT can handle without rebooting all the time?

Nevertheless, there will soon be some new games for my kids. Any suggestions?

PS: just in case you are interested, I am working on j-uae again, fixed quite some nasty bugs, added smaller stuff and hope to release a new version soon ;). Nothing promised of course.

2010-09-03T14:46:00.005+02:00

Border Gadgets!

Most people found those visible aos3 border gadgets ugly.. they are now gone. See for yourself:

Of course any custom border gadgets can't be hidden. Scrolling window contents works in real time, you won't notice any difference here. In the screenshot above, you can see the AROS multiview window (left) and the amigaOS 3 multiview window (right), both displaying the amigaOS s:user-startup.

There is still some random lockup-bug remaining. If it occurs, you cannot click in any amigaos window, not even the first one appearing. But if it works at all, it works quite good :).

And there seems to be a bug in AROS intuition: If you add the border gadgets during OpenWindow, they are drawn perfectly. If you add the same gadgets with AddGList later, some pixels on the right border are cut off, as you can see above..

2010-08-12T09:54:00.002+02:00

and six weeks work..

Sorry for being so quiet, but after my vacation there is much too much day-job work on my desk and in my brain. Also my kids have summer vacation, which requires me to take care of them from time to time, when my wife has to work.

So as a conclusion, no time for AROS at the moment, but I am following the mailing list and the forums.

I should have more time in a few weeks, at least then I will give AROS a higher priority in my schedule.

2010-06-18T15:20:00.003+02:00

three weeks break

The next three weeks, no updates will happen here. I will enjoy this time with my wife and my kids. This works best (only), if I have no chance to use a keyboard ;).

Other than that, I wanted to finish the border gadget integration before that break. It is working now, even the proportional gadgets are working to a certain degree, but the code is a clear mess ATM. I hope, I can clean it up, when I return. It is most likely not a good idea, to leave it in the current state, but I can live with that.

All current code is in the svn, so in case my plane crashes, the sources are safe ;).

2010-06-09T13:43:00.003+02:00

Border Gadgets

I always said, it would be impossible to get rid of the amigaOS border scroll gadgets. But it always tempted me to try. Well, see yourself:

It is not yet perfect, the arrow keys work and the proportional gadget size is in sync. But at the moment you cannot move the AROS proportional gadget. Other than that, I like it :). The original gadgets will be hidden as soon as I am done with debugging of course.

There seems to be a bug in intuition's NewModifyProp, as it does not work with my border gadgets. It refuses to modify my proportional gadgets, as they are GTYP_CUSTOMGADGET and not GTYP_PROPGADGET, but they are objects of type PROPGCLASS. I need to find out, what the problem is here. Might be, that GZZ windows cause the problem.. It took me quite some hours to find that bug, without aros being open source, it would have been impossible. On the other hand, I suppose the closed source amigaOSes don't have such bugs ;).

2010-05-25T13:43:00.004+02:00

Small steps..

Time is as usually limited, but there is still some improvement. It seems, that Paolo is satisfied with the 0.7 he got for the next Icaros version. At least, I got no further complaints from him, after I fixed some reported problems.

New stuff in the SVN (not everything already in the 0.7):
- Catweasel support by spirantho
- console output now uses stdout instead of stderr
- coherence mode uses delta buffer for gfx updates
- (some more I forgot..)

cc4 (cc5?) reported, that every new amigaOS window slows down his machine quite noticeable, so I had a look at the gfx optimization. UAE uses a delta buffer to decide, which areas of the display to update. J-UAE updated all windows completely. And as every amigaOS window has an own AROS window, the effort to update all of them was maybe too much. Funnily on my hosted AROS it was not so bad as on his native box. It seems to be related to which resolutions/depths you use.

Nevertheless, the current svn version uses the delta buffer algorithm. But now there are quite some situations (race conditions etc), in which the update is not complete. They are hard to handle. But I think, I got most of them at least somewhat hidden. But it is worth the speed gain ;).

2010-04-16T14:14:00.002+02:00

v0.7 release candidate

Today I sent a link to a v0.7 rc to some brave beta testers, it should fulfill *all* requirements of the bounty.

Main changes compared to the 0.6 on IcAROS:
- public screens are working (again)
- mouse pointer gets hidden (if AROS supports it)
- MUI menus work now
- popup menus (done via real intuition windows as in MUI) work now
- re-enabled old sound code, which (according to clusteruk) even works
- fixed garbage shape window, if toggled integration
- added more resolutions
- destroyed uae window content is now restored correctly
- uae integration now works, if you use assigns as hardfiles
- 68k apps should be able to start from amidock, if j-uae is running already

2010-04-13T18:35:00.003+02:00

MUI part #2

Next thing I noticed was, that MUI popup menus were not working, too. So I had some debugging fun to find out, how MUI does those nice popup menus..

If you click on an object with a popup menu (RMBTRAP set)
- MUI opens a new intuition window for the popup menu
- MUI opens it INACTIVE
- the popup window does not get any mouse move messages, as it is not active
- I assume, it reads the mouse coordinates itself or gets them forwarded by the main window
- as soon as you click in the popup window, it is activated
- if you activate a popup window, it reports the selected item back and closes itself

Nice magic, maybe that's one of the reasons for the name of this toolkit ;).

So I had to make all that possible for integrated j-uae windows, too. Open inactive windows, let them get mouse moves, keep the right button pressed all the time and so on. But now, they work:

2010-04-13T18:21:00.003+02:00

MUI part #1

I was on the search for an application, which really uses public screens. Not so easy for someone, who did not use AmigaOS for quite some time ;). But of course, every MUI application can run on a public screen. Just use the settings menu .. SETTINGS MENU!?

No MUI application had menus, if run in j-uae integration mode :(.

I noticed, that some application might change their WFLG_RMBTRAP flag for every mouse move.. if the application wants a normal intuition menu, it clears the flag, as soon as the mouse moves over a gadget, which handles right clicks itself, it clears it. So for every mouse move, MUI asks the underlying gadget, if it has a popup menu or something like that. Btw, ZUNE does it the same way..

Not really elegant as you could just always have WFLG_RMBTRAP cleared and in case someone picks a menu over such a gadget you can always send a MENUCANCEL and get the same effect. You then receive the same message again, as if WFLG_RMBTRAP was set. You just have do do this on every mouse click and not on every mouse move.. Maybe I should try, if it really can work the other way in ZUNE..

Anyways, MUI seems to do it for every mouse move :( and so integration had no chance to notice it.

For the AROS side, we do it the elegant way now: If we get a MENUVERIFY message, we look at the according aos3 window. If it has WFLG_RMBTRAP cleared at the time of the mouse click, we display an according AROS intuition menu.

If WFLG_RMBTRAP is set in aos3, we just send a right click event to the aos3 window.

So now all MUI windows have working Intuition menus :).

2010-03-22T16:26:00.003+01:00

Happy Birthday!

I just noticed, that I registered the janus-uae project on sourceforge on 2009-03-20! Time passes really quick.. I really thought, I could do it (much) faster. At least I am sure, that it won't take another year until it is completed ;).

What's happening at the moment?
- I added some magic to hide the aros mouse pointer
- fixed a bug in borderless windows
- fixed a bug, which caused native j-uae to always crash as soon as integration was on
- fixed a bug, which appeared because of bugfix above ;)
- fixed a bug..

That's where I am at the moment. It is a quite complex piece of software, so if you fix a bug at one place, you really need to test everything else, if it is still ok. So no new features for you to see here. Just less bugs (hopefully).

OT: And for all planet-aros users, Rob's cron job seems to be dead, so you don't get any updates there.

2010-02-18T11:56:00.003+01:00

Problem fixed

Thanks to Ball000, who showed me a way, to hide a window (and make in reappear again!), no bad hack is necessary any more to hide the main uae window. ChangeWindowShape is my new friend now :). But I still have no idea, how to make a window opened with WA_Visible=FALSE visible again ;). But it does not matter any more.

clusteruk wanted more memory in amigaOS, the next version will have it:

If you try to give too much memory to amigaOS, you don't get an error message, you just get 0MB of ZIII ram.

2010-02-17T17:17:00.002+01:00

From hosted to virtual

When I spread a v0.5 to some people, I did get quite disappointing results. Not many of them managed to get it working. It worked perfectly for my AROS hosted on Linux, but only very rare and unstable on their native machines.

Up to now, I did not have a native AROS around, but I did not want to get some real hardware here. QEMU and VirtualBox are not really working stable on this machine, I think they don't like VMWare already running. But I found an old Icaros VE 1.1 image for VMWare, so I will use that for my native tests. Network works, so I wrote a little script, which fetches the binaries from my build machine (another virtual VMWare guest). WGet is really working well on AROS. I was really happy, that wget is available and a little bit surprised, too ;).

And yes, j-uae does not run well on a native host, if it runs at all. Strange..

Back when I started, I had to hide the main UAE window in order to show only the coherent windows. I tried a hack, just resize it to a 1x1 pixel big window and place it in the lower right corner of the screen. If the user switches back from coherent mode, I just resized it to the original values again. Works nice on hosted. Works *not* on native, as it seems.

But UAE does not really run well without its main window. And I did not want to fix that. So I saw, that you can open a window with WA_Hide in AROS. And it is really hidden! The only thing I did not find (not even in the sources) was a way, to show it again (is there one?).

So now I open a hidden window for coherent mode, if the user changes, I open a visible window and close the invisible one. Problem is, I have to protect all accesses to the main window struct with a semaphore. I hope, this does not cost too much of performance, but so far it seems ok.

So at the moment, j-uae runs on my "native" machine, too :). But I just did a quick test, there are for sure still some bugs remaining..

2010-02-10T17:16:00.002+01:00

Just a test ..

and no, it is not working. No, I don't know, if I will finish it ;).

This is just a dummy stub, which lacks all host features. The only thing it can do, is print some debug messages:


bsdsock.c:314  host_sbinit(): NOT YET IMPLEMENTED!
bsdsock.c:274  locksigqueue(): NOT YET IMPLEMENTED!
bsdsock.c:282  unlocksigqueue(): NOT YET IMPLEMENTED!
bsdsock.c:2750  host_gethostname(): NOT YET IMPLEMENTED!
bsdsock.c:2616  host_getservbynameport(): NOT YET IMPLEMENTED!
bsdsock.c:344  host_sbcleanup(): NOT YET IMPLEMENTED!
bsdsock.c:274  locksigqueue(): NOT YET IMPLEMENTED!
bsdsock.c:282  unlocksigqueue(): NOT YET IMPLEMENTED!

2010-02-10T09:32:00.003+01:00

Weekend

This is totally unrelated to AROS, but it gives you an impression, what I did last weekend :)))) :

2010-02-03T17:15:00.005+01:00

Wanderer integration part 2

All the missing parts are done now, so if you click on a editor and then double click a text file, the editor opens the text file. If it is a 68k AmigaOS editor or not, does not matter anymore. Of course, both the editor and the text file must be accessible (mounted) in AmigaOS.

To make all that stuff safe, to add configuration parameters and to be able to switch it on and off easily, is more work than to get it working for a first time..

And a GUI was missing, too, of course. As the old GUI was not very intuitive (I never was good at GUI design), I gave it another try. So it looks like that now:

So what is the current bounty status?

1. Must be able to run some classical software which must include: WordWorth 6, Organizer 2, Datastore 2 and Money Matters 4.*
Done.

2. Must provide support for window and screen based apps so they appear to be running on the host system - including access to public screens.
Done.

3. Doubling-clicking a 68k application in Wanderer will cause that application to be run in the emulation.
Done.

4. Each instance of emulation will be a commodity that can be shut down via Exchange.
Done.

5. Port over a Zune based UAE prefs application.
Done.

6. UAE to use AROS clipboard.
Done.

7. separate directory (for 68K files) dictated by the chosen config.
Done.

So all features are implemented. Bug fixing and test time!

2010-01-19T16:57:00.002+01:00

Launch Deluxe Paint from Wanderer!

Even so I did not fix all screen related bugs, I was too bored with screen stuff already. So I decided to go for an "easy" target, the integration into wanderer.

I had to add some code to wanderer.c, which is very j-uae specific. But wanderer.c is not the most beautiful code on earth anyways (no offense), so I don't think it does any harm there. As soon as wanderer detects an m68k amigaos binary, it searches for a special public port "J-UAE Execute" and sends a message to it. If the port is not available, the original wanderer functionality is not changed. Wanderer code is not yet committed, as it is not complete yet (parameters will change) and I don't want some incompatible nightlies causing a debugging nightmare for me.

J-uae starts a thread at startup, which opens that port and waits for messages. As soon as one arrives, it checks, if the path of the clicked icon is inside an in amigaOS mounted volume and if launchd is running. The tread then stores the command in a linked list (GSList, sorry) and sends a signal to the amigaOS launchd, which you should have started in s:startup-sequence of your amigaOS installation for example.

Now the launchd calls a trap to get the next command from the j-uae master thread and the tries to start it with the help of the wbstart.library from aminet. As soon as launchd got his command, j-uae master deletes the command from the list.

As launchd is independent of all other j-uae features, you can use it in a non-integrated j-uae environment, too of course.

Three things are still missing:
- error handling/messages
- buffer overflow checks, if path gets too long
- wb parameters

All solvable, but boring ;). So enough for today :).

2009-12-16T13:03:00.004+01:00

Christmas time..

But it is not yet time for presents, sorry.

I decided not to release a 0.4, as there was not much feedback, if it worked or not. If you have it working and you found no major bugs, drop a note here, please.

So I went back to my road map and got custom screen support ready. You can now start Deluxe Paint III for example from your amigaOS workbench and it opens on an AROS custom screen. Screen cycling works, too, so if you have many AROS/amigaOS screens mixed, you can use the cycle gadgets just as for native screens (those are native screens).

Downside with custom screens is, that you don't get nice looking AROS menus and window borders, as the program can do too much nonsense with custom screens. So Deluxe Paint looks like Deluxe Paint always looked ;). So no need to show you a screen shot here ;).

And of course every screen gets its own process. Custom screen windows not, as amigaOS windows on custom screens don't have related AROS windows. For custom screens, we don't go down to the window level. So the output of (AROS) tasklist can look like that (some columns stripped):


address         type    state    name    
0xAF86DFE8      CLI     running  tasklist
0xAB676FF0      task    ready    Idle Task
0xAB706548      task    waiting  x11hidd task
0xAB683550      task    waiting  UnixIO.task
0xAB6C1AF0      task    waiting  input.device
0xAB6D1838      task    waiting  Menu Handler 
0xAB6EF298      task    waiting  console.device
0xAB717CA0      process waiting  J-UAE semaphore proxy
0xAB741478      process waiting  CON: Window
0xAF88DEA0      process waiting  CON: Window
0xAB7E0E38      process waiting  xpipe.handler process 
0xAB74C228      CLI     waiting  IPrefs
0xAB7AB6B0      CLI     waiting  ConClip 
0xAB820030      CLI     waiting  C:RexxMast
0xAB826378      CLI     waiting  Decoration
0xAB7D1828      process waiting  pipefs.handler process 
0xAB95CD48      process waiting  Workbench Handler 
0xAB6FB580      process waiting  Lib & Dev Loader Daemon
0xAB71F3C0      process waiting  filesys process for RAM 
0xAF77C810      process waiting  AOS3 Window 0
0xAF762A00      process waiting  AOS3 Custom Screen 100a1c60
0xAB6DCEF8      task    waiting  Screennotify Handler 
0xAF7BA7B0      process waiting  AOS3 Custom Screen 102f2d28
0xAF807730      process waiting  AOS3 Window 0
0xAF7BD458      process waiting  AOS3 Window 104b6ee4
0xAF7BA008      process waiting  AOS3 Window 104b6a8c
0xAF6D1418      process waiting  AOS3 Window 104b4f9c
0xAE43C8B0      process waiting  AOS3 Window 104b45fc
0xAF7AA888      process waiting  AOS3 Window 100a314c
0xAF793D30      process waiting  AOS3 Window 100a241c
0xAF734708      process waiting  AOS3 Window 1000e834
0xAF735520      process waiting  AOS3 Window 1000239c
0xAB953AA8      CLI     waiting  WANDERER:Wanderer
0xAB7187C8      process waiting  UAE thread
0xAB7125F0      CLI     waiting  uae

After a long period of not having spare time for j-uae, things went better the last few weeks, so the activity rose again:

Not that it is sufficient, but much better.

So what's up next? Getting public screen support back working. You can compare that to AROS x86-32 bit and AROS x86-64 bit. 64 Bit has some nice new kernel features. Now I need to merge the new custom screen stuff to the public screen code, too ;).

2009-10-28T16:59:00.002+01:00

another release candidate

As there were some problems with the last release candidate, there is another one here.

The following things are different:
- mouse sync in overscan modes should work now (please test!)
- a lot of new and bigger picasso screen modes added
- janusd-draggable for those who want to use j-uae without coherence (this is just a quick work-around)

Mouse sync for non-picasso screens was written from scratch, it took quite some time (much more as you might think). The result is a small and clean code segment, which hopefully works now for all weird overscan settings.

For the bigger screen modes: you need to have an at least so big wanderer screen to use them and assign enough ram to the picasso96 emulation in the memory tab.

I am waiting for your bug reports, either here, by e-mail or on aros-exec.

For all news sites: This is still no news you should put on your site. You may publish it next week, when the 0.4 is uploaded to the official servers. Thanks.

2009-10-15T16:33:00.003+02:00

For the brave

As you all wanted a new version, I compiled a release candidate for a 0.4 j-uae. If you don't find any bigger problems with this version, I'll upload it to the aros archives next week.

I have not tested it very much, it is more or less just a current build of the SVN.

But I've added the GUI buttons to enable and disable all the new features:

You can download the release candidate archive here.

Keep in mind, this is not a 1.0 version. This is not even a 0.4 ;). And read the readme.txt in the archives docs section.

Please report severe bugs by e-mail or here in the comments section.

Well, reports of a great and working version are welcome here, too. Although more unlikely to happen ;).

For all news sites: This is not a news you should put on your site. You may publish it next week, when the 0.4 is uploaded to the official servers. Thanks.

2009-10-09T14:47:00.002+02:00

Mouse in sync

After quite some fiddling with a lot of parameters, it seems, that the AROS and amigaOS mouse pointers are now in sync both on amigaOS native and Picasso96 screens, both if j-uae is run full screen or in window mode. Of course, janusd needs to be running.

ScanDoubled and Overscan screen modes are not working, could be done of course. If somebody really needs those, well, he might add them himself (or beg me).

I wanted to show you a screen shot, but you could only see one mouse pointer on it ;).

During movement of the mouse, the amigaOS pointer may lack behind, but it is tolerable I think.

I really should release a new version, as j-uae now has clipboard support and mouse sync, it should be useful, even if you do not use the coherence mode..

Do you want one?

2009-09-16T14:53:00.004+02:00

Small steps

Spare time is still an issue, but at least there were a few commits by me.

I am trying to get the pointers in sync on non-Picasso96 screens. For P96 screens this is rather trivial, as I know, where the upper left corner of the amigaOS screen in compared to my AROS mouse coordinates.

It all comes down to coordinates conversion from AROS to amigaOS.

WinUAE does this different, it just hides the windows pointer and so the amigaOS mouse is the only one existing.

Somehow I don't like this. I take the AROS mouse coordinates and try to move the amigaOS mouse exactly below the AROS mouse. For P96 this works perfectly.

For OCS/ECS/AGA screens, there is some kind of border around the screen, which (for me) is hard to calculate. But I seem to be getting there.

But as life goes, I triggered quite a bug in the Gtk GUI. It uses arrays to store the widget pointers, for example an array, which hold all sound option widgets (One widget for "mono" and so on).

Those arrays were not NULL terminated, so it was hard to say, how many elements were in there. And there were quite some code parts like that:


while(array[i++]) {
  do_sth(array[i]);
}

Which of course terminates not really on the end of the array. So I ended up, NULL terminating all arrays. Still some crashes. So I ended up recounting all possible elements of those arrays and correcting the size of them. Boring work, but now it stopped crashing.

Bad thing is, that I also found a too small array in code written by me ;).

So what is the lesson for today: C arrays are evil. Sometimes.

2009-08-18T16:30:00.004+02:00

Progress? What progress?

At the moment, I have nearly no time to code for j-uae. 1h/week does not bring you much further, sorry. I have a lot of "day-job work" to do and the remaining time gets my family and friends.

What is the current bounty status?

1. Must be able to run some classical software which must include: WordWorth 6, Organizer 2, Datastore 2 and Money Matters 4.

WordWorth works on a public screen. Other programs not tested/available, but I see no reason, why the should fail.

2. Must provide support for window and screen based apps so they appear to be running on the host system - including access to public screens.

Public Screens are fine. You can have aros windows on amigaOS public screens and vice versa (still needs some debugging, but will work).

3. Doubling-clicking a 68k application in Wanderer will cause that application to be run in the emulation.

Missing (not started)

4. Each instance of emulation will be a commodity that can be shut down via Exchange.

As you wish. But I don't see the point in here, one instance is enough. But it is a commodity, you can start more than once.

5. Port over a Zune based UAE prefs application.

Done.

6. UAE to use AROS clipboard.

Done.

7. separate directory (for 68K files) dictated by the chosen config.

Not really sure, what this means. UAE handles it this way already.

So what is still missing?

- custom screen support

Should be trivial, as j-uae already can run in full screen mode. But e-uae was never designed to switch between windowed/fullscreen mode on the fly. Opening a custom screen works already, but the closing/switching part is missing completely. I am working on that at the moment, whenever I find some time.

- wanderer start

I will keep that simple and just launch the program without any parameters etc. Should be quite easy. Fancy features like parameters etc can be added later, otherwise this bounty will never be done.

What next?

Vacation. One week. Then we see any further ;).

2009-07-21T10:49:00.003+02:00

emulation heaven

Nothing happened to my code for quite some time, sorry. No spare time -> no code.

So this blog entry is the best I can do for you ;).

Did you ever wonder, how my development machine looks like? I'll give you an impression.

The only native operating system is Windows XP. It runs two things:
- an X Server (Xming) and
- VMWare

In VMWare I run Debian (and sometimes IcAros). Debian opens quite some xterms on the X Server (rootless).

In those xterms, tirc is running as my irc client and I can start AROS from there. So AROS is running on Xming, too.

Now inside AROS, I can run j-uae (rootless of course).

It's a pity, AROS can not run rootless, otherwise I would really loose the overview, which window runs where ;).

And this is where it ends (this is just one X11 window):

This is m68k-ffplay (new version from aminet) running rootless inside j-uae, which is running on x86-aros running linux hosted running in VMware on Windows XP.

Any further questions?

Btw, the video runs quite smooth, fascinating.

The only remaining question is, which DS9 episode is being played ;)?

2009-07-06T12:05:00.001+02:00

"screenshot of cut and paste in action with e.g. Wordworth"

For Manu:

2009-07-02T15:36:00.002+02:00

IDCMP Bug

Sometimes the amigaOS side simply died and was frozen. I was hunting this bug for quite some time now. But with clipboard support, it happened way too often. But I was not able to find any problems in my code. All function returned, but sometimes, amigaOS display was simply locked.

So finally I managed to reproduce the problem, surprisingly without even any clipboard interaction.

The problem seems to be, that AROS sends IDCMP_MENUVERIFY messages not only to the active window, but to *all* windows. I switch off the amigaOS-display-to-aros-display copy, as soon as a MENUVERIFY is received and switch it on, as soon as a MENUPICK is received, I got a locked display, as MENUPICKs are *not* sent to all windows.

I did not discover this problem earlier, because I never tried to select any menu in AROS, when I tested j-uae. For clipboard testing, I did a lot of copy/paste with the help of menus.

As MENUVERIFY messages normally cause no harm and are invisible to the users, this bug is likely to cause no bigger problems. But for j-uae it is very harmful.

Nevertheless, found it. Wrote a quick work-around in j-uae and the problem is gone.

Let's see, if I try to fix it in AROS (or just use the Bugtracker ;)).

2009-06-30T15:26:00.003+02:00

Clipboard #2

Now as clipd and janusd should be able to work together, I was tempted to try it ;):

You can see the amigaOS 68k JanoEditor and the default AROS x86 Editor. Both are running side by side. You can select the copy/paste menus of both (they share the same AROS look and feel of course) and transfer data from AROS to amigaOS and vice versa.

After some playing around, the 68k side was locked :(. Still some bug hunting left, as it seems..

use_gui=no

I've also changed the configuration GUI. In e-uae you have either the possibility to run with a GUI and get this GUI if you start e-uae. Or you start without a GUI and get directly to the UAE window, but you can't get into the GUI later on.

Now the GUI is always started, but as j-uae is a commodity, you can hide/show it with exchange at any time. uaerc.config option "use_gui" just controls, if j-uae starts in show or hide mode.

Planet AROS

If everything works, this post should also be available from Rob's Planet AROS. Try it, if you did not come from there. I really find this a good idea, thnx Rob.

2009-06-19T13:35:00.003+02:00

Clipboard

Currently I am working on clipboard sharing. I had a look at the WinUAE sources, as it now also has clipboard sharing available. But I was not able to use any of their code. First they code all the m68k parts in assembler. Even if I really like m68k assembler, C has it advantages. Second thing is, they have all assembler parts in one file (filesystem.asm), which hasn't been updated in e-uae for quite a while (2007). Third, they exchange clipboard data on every clipboard change. So if you copy the clipboard, it is synced at once. I wanted to sync it only, if necessary.

Good thing is, that all the clipboard content parsing, WinUAE has to do, is not necessary for us. You can copy amigaOS clipboard data without modification to the AROS clipboard, as both have an IFF structure.

So now there is a small m68k program (clipd), which you can start in user-startup for example. As soon as it runs, you can enable/disable clipboard sharing in the j-uae gui.

Clipd is independent of janusd, so you can also use it in normal uae mode.

So far it is working only partially. Problem is, that there are quite often freezes and I am not so sure, why. Clipboard.device blocks writes as long as there is a read. Somehow this happens too often for me. Maybe there is some kind of race condition somewhere in my code. Or aros clipboard.device is buggy.

One thing I noticed in aros clipboard.device is, that it behaves different, if you don't supply a buffer for reading. In amigaOS you can find out the current size of the clipboard with data=NULL, on AROS you just get back -1. I will commit a fix for that as soon as I have everything working stable in j-uae.

My time is quite limited at the moment, so expect slow progress in the next weeks.

Have a nice weekend.

2009-05-29T14:38:00.004+02:00

Deadline

A deadline is a deadline is a deadline, but only between Ferengi (17. rule of programming).

I noticed, the deadline for this bounty is quite near (1.6.) but obviously, it will be missed. Normally I am better in keeping my time schedules, but this is not my main business, so estimates are hard sometimes.

I asked the power2people to extend the time period, but they prefer to keep the original deadline, as long as the bounty is still assigned. My personal new deadline is the 1.9. as I expect to have less time for coding in the next months, that is why I wanted to have it completed till 1.6..

Anyways, it will be done sooner or later ;).

I will be off-line the next few days, so you won't get much news here.

2009-05-26T16:38:00.003+02:00

another step completed

Up to now, you had to start the janusd from amigaos3 and then got your rootless aos3 windows. There was no way back to normal uae operation and. If you quit uae, all janus-windows stayed forever on the aros workbench.

Since now you can:
- change from coherent to normal by sending CTRL-C/CTRL-D to janusd (from aos3)
- change from coherent to normal with a new GUI tab
- save coherent mode in the prefs

All the above is of course only possible, if you have started janusd already (for example in your amigaOS startup-sequence).

Have a look yourself.

Above you can see the new GUI tab "View", which is disabled, as long as janusd is not running.

Janusd started, normal mode.

Coherence mode on. The normal UAE window is still open, I'll keep it there for debug reasons. For the release version, this will disappear of course.

Next step? As you can see in the "View" tab, clipboard support. This will be a small aos3 program on its own, so you can use transparent clipboard sharing in "normal" uae mode, too. But you need some more patience for that ;).

2009-05-19T16:41:00.003+02:00

small steps

For quite some time, I had problems with the DoubleMenuRequesters used by WordWorth. I am not sure, if I ever have noticed, that amigaOS has something like that ;). They appear, if you double click on a wrongly spelled word for example. Double click with the right mouse button. There is no way for me to catch such double clicks from AROS. I could setup my own DMRequester, but this will only appear and not give me any chance to jump into some callback and hand it over to amigaOS.

So I now measure the time between two menu pick events with no menu selection. If this time is quite short, I send two right mouse button clicks to the emulated environment. Seems to work.

But then, whenever such a !!=!(§"!! requester appeared, my window sync algorithm caused indefinite window cycling and I had no idea why for quite some time. The cause was,that as long as the requester was active, there were two layers, which had the same window pointer. Until then, I never got double entries in this list. After I ignored duplicates, it works as expected.

Small features are sometimes paid with a lot of time:

2009-05-14T15:36:00.003+02:00

Another new machine..

I already had the feeling, that the change to my new installation would take more time, than I have. I upgraded to the latest Debian and .. AROS hosted crawled .. I spent some time trying to debug it, but after some days I had to give up, otherwise j-uae will never get finished. So I installed another machine (this time with etch and not lenny) with an older debian release. At least I did it all on virtual machines, so copy etc. was rather trivial. Nevertheless, 10 days have passed without any process on j-uae.

Current status:

I can build AROS and j-uae without problems now. Building is much faster now, but it could be still faster ;).

AROS runs without problems (virtual Debian on VMware (Windows host), X display running on XMing Server on Windows)

j-uae file system fixed, now uses amiga API on some places, where problems with libc calls appeared on the new machine (?).

So if nothing else pops up, I hope I can do something productive next time I switch this machine on.

And another screenshot for you, compare the past and the future ;):

2009-05-04T09:59:00.002+02:00

New machine

As you might wonder, what I am doing at the moment, I'll give you an update.

Menu stuff is already working, so I can select a menu from AROS and the appropriate amigaOS menu gets activated. But it still needs debugging and I wanted to debug it with the help of WordWorth. WordWorh needs quite some CPU power and my old debug machine was a 1GHz PIII with 512MB of RAM. It was also crashing as soon as either to much harddisk IO or a too high CPU load happened. So compiling AROS (without contrib) took an eternity and caused some 3-4 reboots. But it had the advantage, that you keep your code fast and optimized, as you notice speed problems at once.

But there is a time, where you simply have to migrate to a new machine and that was now. I already had a new dual core/2GB ram machine standing beside my old one for quite some time. But setting up a development environment as I like it takes time and I was never motivated to spend it.

So after a few hours (days ?), I did my first build of j-uae a few minutes ago, so back at work.

2009-04-17T14:58:00.002+02:00

Menu - step 1 completed

Now Menus are really looking good, as you can see here:

This is a screen shot of WordWorth 7 running on the AROS wanderer screen.

The most difficult part of this menu integration were the menubars, as the are not detectable from the Intuition Menu structures. Simple things are not always simple.

2009-04-15T10:43:00.003+02:00

Menu - first step

You might probably ask, what is going on in janus land. I was fighting with IDCMP stuff for quite a while. After some prototypes and searching the holy archives of comp.sys.amiga.programmer I accepted, that this is no way to go. Newsgroups are really nice to search for old stuff. It's a pity all the (sometimes valuable) data in those new and hype forums will disappear as soon as the forum dies :(.

So I started doing the other side of menu integration. Clone the amigaOS menus, so that they appear as AROS ones. I have to admit, I've never done menu "low level" stuff, I always used Zune menus. So I looked at gadtools, learned how intuition menus are linked together. As so many requested some new screenshots, here is one with the very first menus:

What you can see here is the menu of the aos3 non-backdrop workbench. Clicking on the menu does nothing for now, sub-menus are sill missing and all the menus flags are still ignored. A lot of other things need to be done, too, but as the basics work, the rest is just boring work.

For the menu selection I have an idea already, how I might solve the IDCMP trouble easily. I'll keep you posted.

2009-04-08T14:28:00.002+02:00

To close a window

First of all, I've merged all relevant changes, which were done in e-uae after the WIP4 release. Not much noticeable for a normal user, but might fix some smaller issues.

Besides that, you now can close aos3 windows from the AROS side. So a click on a AROS window, which is the clone of a aos3 window closes the aos3 window. Then the daemon detects, that a aos3 window got closed and kills the clone. This is necessary, as things like "Do you really want to close this window" must work of course.

I thought to send a faked IDCMP message to the aos3 window, which in fact worked at a first glance. But aos3 CLI windows don't have a port to receive IDCMP messages at all. How do they notice, that the close gadget was pressed at all?

As I had no idea, I went the easier way. Assuming the close gadget is always on the top left of the window border, I just move the mouse there, "press" the left button and move the mouse back to it's original position. Much simpler, not so elegant, but works always (as long as the close gadget is, where it is supposed to be ;)).

What's next? Menu stuff..? I have no good ideas here, but we'll see.

2009-03-25T16:25:00.002+01:00

SVN

It was for sure time, to set up some reasonable source code repository, other then daily tar backups of my local sources. So from now on, the sources are hosted in a SVN repository at:

https://sourceforge.net/projects/janus-uae/

So now I don't need this blog any more, you can watch the sources yourself ;).

2009-03-25T10:58:00.002+01:00

Janus-UAE v0.3 released

After some fighting with the new display panel (thanks Paolo for reporting the bug) v0.3 finally is on http://archives.aros-exec.org/.

New things compared to v0.2:
- picasso96 startup bug fixed
- full screen modes working
- new GUI tab "Display" replacing old "Chipset"
- GUI can be hidden (and shown again) via exchange
- exchange can quit J-UAE
- janus daemon has experimental public screen support

I am at the moment setting up an SVN repository for the sources, so it will be easier for the interested to get them.

2009-03-13T11:46:00.005+01:00

Display Settings

As a GUI is part of the bounty, I had to add a configuration page for the full screen mode of course. Up to now, there was a configuration page for the Amiga chipset:

I took a look at WinUAE and (more or less) cloned its "Display" tab:

This is the result:

So now you can change both the full screen option of j-uae (all possible resolutions) and the window size for the windowed mode. At least, if all the hooks are working. So far only the right four frames and the Emulation Speed frame is working.

Btw, this is one GtkTable. Such a table class is missing in Zune, maybe I should convert my GtkTable code one day into a Zune custom class. But not today ;).

Why GTK at all was a question? Because the complete GUI is written in GTK as it was already available for E-UAE. At some places it looks not perfect, but the GUI is quite complex with all the dependencies, so doing a new one in native Zune would be quite an effort.

The whole Display tab is one GTK class, which emits signals if there are changes and exports the values of the settings.

What's still missing in this tab:
- at startup set all values according to the last saved prefs
- hooks for the resolutions and resolution options
- disable all frames, if UAE is running

2009-03-09T17:01:00.002+01:00

v0.3 ?

- UAE running full screen on AROS works
- amigaOS public screens as AROS public screens, too

What's missing?

A GUI for the full screen modes. I am not good in GTK, even if I did GTK-MUI ;). So this is no fun for me. We'll see.

Screenshot:

Yeah, not much new to see, but I've told you so ;).

2009-03-05T11:34:00.005+01:00

Public Screens

Just to break the silence, I am working on public screen support for janus-uae. The idea is to open an AROS public screen for every amigaOS public screen. So AROS windows and amigaOS windows can both live on that screen. So far for the theory. I introduced a bug somewhere and that's where I am, debugging ;).

Btw, my actual janus-uae build can run in full screen mode, but so far there is no GUI button to activate that. v0.3 will have it, promised ;).

Btw2, did anybody try the janus-daemon in the amiga directory of the janus-uae v0.2? Just start it form a shell window on a picasso96 workbench screen and get a feeling, how the integration will look like. Still very much work in progress, so be warned.

2009-02-27T09:34:00.002+01:00

Nobody?

Up to now there have been 90 janus-uae v0.2 downloads from aminet and the archives. Not bad for a 0.2 which only offered picasso96 support compared to the old e-uae. Only?

Are you afraid, the demon in the tar will rape you in your bed at night,
The wisdom of ages, the lies and outrages concealed
Time it waits for no man
The future is revealed
Time it waits for no man
Janus fate is sealed ;).

Btw, I found on youtube, why E-UAE is so cool on VmwAROS :).

2009-02-19T11:36:00.002+01:00

Janus-UAE 0.2

Today I uploaded version 0.2 of Janus-UAE to the AROS archives. If you start it, you'll get an e-uae with picasso96 support for AROS. I thought, some people might want such a version.

For the completion of the bounty, quite some stuff is still missing.

2009-02-04T13:38:00.002+01:00

Optimization

Still there are no visual improvements over the already known screenshots. But now the gfx updates are as smooth as the real uae updates. There is still one minor error, which causes non updated backgrounds, but beside this, I like it.

What was the problem?

The Janus-UAE picasso96 code is responsible for the copy operation from the picasso memory to the different AROS windows, which have AmigaOS counterparts. For a first quick solution, I always copied all window contents from the AmigaOS sode to the AROS windows. Not really optimal. Picasso96 knows, which areas have been changed, but .. it does know nothing about intuition windows.

So now, whenever picasso96 detects changed areas, I update the area in all windows, which are withing this area. Still too many updates, but much better than before. So as long as only one window is within the area it is optimal. If you have really many windows stacked, you loose a little bit, but you should not notice it.

Besides that, I tried to fix the build system .. I made some progress here, but it is not really a configure & make solution yet. I always end up with -I/usr/include and -L/usr/lib defines and I am not sure, where they come from. But if I sed them ou of my makefiles, the build works.

Another thing I started, is to get rid of compiler warnings .. also quite some way to go ;).

2009-01-28T10:50:00.005+01:00

Something completely different

There's a time to code and a time to ski. I've been in Bad Gastein in Austria last weekend. Despite the really bad weather forecast, we really were lucky:

We even got some powder :))):

The only thing, we did not get enough, was sleep. In Bad Gastein you can find very good party locations, no typical Austrian After Ski stuff, but nice (and drunken) people from Sweden, Denmark and Norway and cool live bands everywhere (also from these countries).

So if you want to listen to Iron Maiden and AC/DC instead of "Anton aus Tirol", Bad Gastein is your place to go ;). Best band in my eyes I've seen there were the Afterskindians with singer (and pyromaniac ) Johan Fahlberg, who played in the Silver Bullet Bar. No (publishable) pictures from inside the bar, sorry ;).

2009-01-21T15:32:00.003+01:00

Another Screenshot

So what am I doing at the moment? Not much visible in screenshots.

I am cleaning up the code, I have written so far. It was quite some try and error stuff in there, many different ways to do one thing, as I wanted to get a feeling, what works, and what makes problems.

Now it was time to clean up the mess and do some bug hunting, everything now works as expected. Not everything you wish, everything I have done so far ;).

So have a look yourself:

You can see here workbench running in an AROS window, three open shells, one is AmigaOS3 and the other three are from AROS. You can resize, move and depth-arrange all those windows. You can type in those windows and click on the icons. Speed is nearly normal E-UAE speed, not faster obviously.

What does not work at the moment for AmigaOS:
- close gadget
- menus
- border gadgets
- non Workbench Screens

So far no patches to AROS are required. AmigaOS got one SetFunc for CloseWindow, because otherwise it would have been too dangerous, that a window structure gets freed during access from the AROS task.

I really think, that border gadgets are the most difficult task remaining, as there might be everything in there. I have only tried WordWorth for a test so far, but WW has plenty of custom border gadgets, those a really a feature, C= should have never introduced.

And of course you cannot start AmigaOS programs from wanderer icons yet. So far, you need an open AmigaOS window (for example) workbench, to launch others.

2009-01-15T16:27:00.003+01:00

I can type, click and move my mouse!

If you have the right idea, difficult stuff is much easier, than the stuff you thought would be trivial. It took me days, until I had the window swapping and positioning working. It just took me 20 minutes, to be able to type in a simple shell window from the AROS side.

So I could launch my first AmigaOS program from an AROS window :).

Now for the mouse. What I really hated in E-UAE for AROS is the bad mouse synchronization. I hate double mouse pointers, one following the other quite some pixels after. Getting the actual mouse coordinates from AROS is simple, I have programmed quite some traps now. But what to do with them? How do I place the AmigaOS mouse? I found an old program (SetMouse) on Aminet. Freeware and *with* sources. It saved me a lot of work, so thanks to Ketil Hunn, who did this some 15 years (!) ago.

The AmigaOS mouse is now always *exactly* below the AROS mouse!

Hey people, release your sources! It's really a pity, how many useful programs there would be on Aminet and how much someone could learn from them, if we just have the sources. (And we could also port them, but that is another issue).

So now, I can move the mouse, click on gadgets, resize windows, type where I want.

Hey, we are getting closer :).

2009-01-14T16:07:00.002+01:00

Integrate e-uae .. even more

Now there are window titles, they are not updated at the moment, but this is boring work, really trivial.

The next issue was to move/raise etc. the windows. First there can be an os3 application, which resizes its own window. Then the AROS window needs to be resized accordingly.

Then the AROS user of course should be able to resize his AROS windows, which contain os3 windows, which then must be resized.

I had though out a good solution, which just did not work :(. I found some minor bugs (a lot of os3 workbench windows are simple refresh, they are cloned, but I needed AROS smart refresh ones..), but still everything was unstable.

If you move one window in front of another, Intuition does not do that at once, the MoveWindowInFrontOf call returns and the windows are shuffled later on, when Intuition "finds time". So my way of sorting needed to be thought over and I think, I maybe found a way to do it. At least, it seems to be stable now.

You can now also close an aos3 window and the according AROS window task is signaled an closes his window before he dies.

So move/close/resize/raise windows works now :). Closing AROS windows as no effect so far.

No screenshot for today, you have to trust me ;).

And btw, I think, I found a name for this project, too:

Janus-UAE

I'll keep you posted.

2008-12-23T11:12:00.005+01:00

Integrate e-uae .. a little bit more

The last screenshot showed just one AmigaOS window on the AROS desktop. This was quite fast to do, but required the AmigaOS application's source to be changed.

The actual version opens any window on the workbench screen also on the AROS wanderer screen. The windows are updated dynamically of course.

There are a couple of things *not* working:
- window titles (trivial to fix)
- move/close/resize/raise windows (quite trivial to fix)
- any kind of input from the AROS side (difficult to fix)
- get rid of AmigaOS mouse pointer (easy, if above stuff works)
- sliders etc in the window border (tricky to fix)
- menu stuff (no idea, how to fix)
- hide the uae window (trivial last step)

But besides those issues, it looks quite ok. Yeah, I know, you want to see it. As always for Christmas, I am late at getting presents, so you only get a voucher from me (sorry, I have no idea, how to record a good movie of a X11 window and this old machine would be to slow anyways):

What you can see here:

In the top left, there are the according AROS windows of the AmigaOS windows of the E-UAE running on the right bottom.

Every AmigaOS window has gotten its own AROS task, as you can see in the tasklist in the right CLI window.

But for your present, you have to wait a little bit longer ;).

Merry Christmas!

2008-12-04T11:21:00.003+01:00

Symbian and Software Signing

Well, started to install some Software on my new toy. I learned, that all Software you want to install on your e71 needs to be signed by the developer of that software. If you don't pay for a certificate as a developer, the developer has to do that manually for every IMEI, which wants to install the software. How ill is that?

Btw, I am on vacation next week, so no E-Mails etc. Even if I now have a phone, which can read/send E-Mails and surf the net ;).

2008-12-01T10:50:00.004+01:00

New toy

And now for something completely different, after more than 6 years, I got a new cell phone, a Nokia E71 (my old Siemens S45 is still working and I will keep it ;)):

The E71 has nearly everything, you can think of:
GPS, FM radio, WLAN, USB, Bluetooth, Infrared, Camera, Keyboard, Cardslot, no windows mobile ..

If you can connect a bigger Screen, it would make a nice computer ;).

You can easily watch movies on it, something my old S45 could not do. And the batteries are lasting nearly as long, as my old s45 ones :).

Back to playing with it..

2008-11-25T10:01:00.001+01:00

Integrate uae ..?

2008-11-18T14:30:00.003+01:00

What is this?

Nothing more working at the moment. And this is no commitment to get it working , ok ;) ?

2008-11-04T09:31:00.002+01:00

E-UAE-GTK and GTK-MUI v2.0 released

As some of you might have noticed already, I uploaded E-UAE-GTK and libgtk-mui to the AROS Archives. Sources for E-UAE are included, for libgtk-mui you can get it from the CVS at sf.net.

Some statistics:

The GTK-UI creates 598 Zune objects out of 363 GtkWidgets. Have a look at the structure of the GUI here.

GTK-MUI has approximately 100k lines of C-sources.

Screenshots? Not this time, try it yourself ;).

The GUI really puts a heavy load on Zune, I doubt, there are many GUIs with nearly 600 Zune objects. All objects are added dynamically and sometimes removed, their children moved to a new object and added again to the main window. So from my POV Zune is stable. If all features are like they should be (especially compared to MUI), is another issue ;).

Some things you cannot convert to Zune from GTK. In GTK you can have any depths of menus, Zune simply does not provide this. Every Widget can have its own menu. Difficult on Zune, too. There are many such places, but in general Zune gives you the same power than GTK. But IMHO it looks nicer.

What really is nice in GTK, every Object Class has its name. So you can just query any object and you get back, that it is a GtkLabel for example. Perfect for debugging. All objects also have real types and it is checked, if you cast them correctly. If you access something, which is not a valid object pointer, the application does not die (like in Zune), you get Warning/Error messages. So from a software developers point of view, I would prefer GTK at any time over Zune. From a users POV, Zune simply looks better ;).

So what's next? Nothing so far ;). If anybody wants to use/improve gtk-mui, request CVS access, you are welcome. I will try to fix bugs, if they appear in E-UAE-GTK, but other than that, there are no plans for a v3.0 at the moment.

Maybe I'll praise an Egyptian God in the future and help him raising ;).

2008-10-23T16:40:00.004+02:00

Today is a good day!

There is one thing, which kept me annoying over quite some time. This random crash of e-uae with gtk-mui GUI. At startup, it crashed at a time, where nothing wrong was happening. If you changed build options, it crashed somewehere else. Sometimes it did only crash at 10% of all starts, sometimes at 100%. This was the case after my last changes.

But at least, the crash was now "stable" and reproduceable. Bad thing, if I change anything, it might get random again. But this did not happen luckily.

So I found out, this time the crash happens, if I access the mui object of this GtkCombo object. This mui object works at creation time and at many other occasions, but after many hundreds of code lines, it causes a crash, as soon as it is accessed. Something overwrites it in between.

So I tried to debug with gdb, but I had no luck with watch points. If I attach it to a running aros, I don't have 'findaddr'? If I avoid all that problems, there is no way, to continue aros execution after setting a watch point, maybe I am too stupid for that ;).

So I wrote a small function check_combo, which just accesses the mui object of that GtkCombo widget. i placed that check everywhere and so I could reduce the amount of lines to search to just some 15 lines. classes/clist.c in gtk-mui. But there was nothing wrong:


static ULONG mNew(struct IClass *cl, APTR obj, Msg msg) {
  GtkWidget *widget;
  struct TagItem *tstate, *tag;
  GString *t;
  ULONG columns;
  ULONG i;
  GETDATA;

  obj = (APTR)DoSuperMethodA(cl, obj, msg);

  if(!obj) {
    ErrOut("clist: unable to create object!");
    return (ULONG) NULL;
  }

[..code snipped ..]

 data->list=NListObject,
                ReadListFrame,
                  MUIA_NList_Format,      (ULONG) data->format,
                  MUIA_NList_Title,       TRUE,
                  MUIA_NList_DisplayHook, (ULONG) &hook_display,
               End;

After NListObject, I could not access the GtkCombo object any more. Ok, but where is the problem. I started debugging NList class. Hmm. there was nothing suspicious.

But finally:

GETDATA is defined as

#define GETDATA struct Data *data = (struct Data *)INST_DATA(cl, obj)

And obj is not yet valid at that time. So I moved GETDATA after DoSuperMethod and it worked. I don't want to count the hours I spent on that error.

And as you where so brave to read it all, you might try out the current version of e-uae WIP4 with gtk-mui. get it from here. It's just the gzipped e-uae binary, put in in aros and run it. Should work ;).

You can now even remove floppies during boot time:

2008-10-15T14:51:00.001+02:00

Locale Prefs went Zune

A few minutes ago, I committed the new zune local prefs. Hope you like it ;).

2008-09-17T10:56:00.006+02:00

Locale Progress

I decided to change (hopefully improve) locale prefs a little bit, have a look:

The map with the cities to select is a custom Country_CLASS based on group class. The register is a custom class based on PrefsEditor class. It's a little bit tricky to send MUIA_PrefsEditor_Changed from Country_CLASS, so I simply gave the editor object to the country object as a parameter. I am not really a fan of object orientated coding. Maybe that's the reason, I love GTK more than Zune from a programmers POV ;). But Zune looks better.

Btw, this map is really done nice by the original authors. If I had to code that, it would end up in *much* more lines of code. Pens have their advantage sometimes obviously.

2008-09-12T13:25:00.004+02:00

Locale Prefs continued

Got the Zune part nearly ready, just some smaller elements and a lot of hooks missing ;). But have a look yourself:

That's enough for today, have a nice weekend.

2008-09-10T15:50:00.002+02:00

OT: FinalWriter running on Vista

During a search for a couple of old text files on some of my CD-Roms, I found the Windows-port of FinalWriter, which once was available from the FinalWriter Homepage as a trial version.

As I was sitting on a Vista PC, I though, I give it a try. Well, I thought I give Vista a try, when I installed that PC, that is another problem ;).

And the surprise: This old application runs without problems under Vista SP1, the installer don't cause any problems. So yes, you can run FinalWriter under Vista without UAE.

Sorry, no screenshot here, as this Vista machine blue-screens, as soon as it connects to any network. This is the other problem, spoken above ;).

2008-08-25T17:16:00.003+02:00

MUIM_List_Sort

I spent some time debugging my e-uae gui, which had random crashes at startup and a 100% crash while quitting. I found the quit bug after some time, but the startup problem went from 10% crashes to now nearly 100%. I am still not sure, if this is not a MUI problem.. But it takes a lot of time, which I don't want to spend at the moment.

I was more motivated to convert Locale-Prefs to Zune. I have done the first page:

But as you might notice, the entries in the lists are sorted. At least they were in the old gui. As this did not work in Zune, I noticed, that MUIM_List_Sort was not implemented at all. At least, I did not find it.

So I added MUIM_List_Sort and did MUIV_List_Insert_Sorted for List_Insert. MUIA_List_CompareHook should work now,too. Although I did not test this (Famous last words, I know.).

There are still two registers left, time will come.

2008-07-10T17:13:00.004+02:00

Breaking the silence

I've been busy with a lot of non-AROS related things lately, so not much to post here, sorry.

I alway wanted to continue Rob's webkit work, I had all the required stuff compiled, but the final linking of the webkit demo failed. Still haven't found the time and motivation to continue there, even if I know, I should ;).

GTK-MUI is in a relative stable state, although I am not sure, if it makes sense, to develop it any further. Too many other libraries are missing (not stuff like pango etc), so there are no "easy" ports of GTK applications. But I learned a lot during GTK-MUI, so it was worth the effort. If anybody is interested, the sources are at sf.net of course.

Lately I noticed, that there are still some non-zune prefs out there and I decided to try to convert one. I chose serial, seemed to be the simplest ;).

It looked like that:

After some guessing, how the base zune class for prefs works and how the old prefs program worked at all ;), it now looks zune'isher:

I have committed my changes, next nightly should have it, hope I did not break it ;). First time, I send sth to the AROS SVN, it was about time.

I'll be on vacation the next two weeks, no keyboard. But maybe in 6 months I'll post again, cu

2008-03-13T16:46:00.003+01:00

about my pain

I forgot to add one byte for the malloc of the fontname, which was the cause, that italics did not work. Now it looks pretty good:

The baseline is a few pixels wrong, but I am not sure, why. (Or maybe Rob's screenshot shows sth. wrong ;)? ).

2008-03-13T14:33:00.003+01:00

I can write forever, too

I wanted to do as much with TT_GetPixmap only as possible, but more was required, than I thought. Anyhow, maybe you recognize the following:

No italics for now, otherwise I would need to post the core dump ;).

2008-03-12T14:21:00.004+01:00

ttengine's way to Cairo

I wanted to help Rob (at least a little bit), so I tried to get cairo working on top of ttengine.library instead of bullet.library. After some more or less stupid bugs and some reading of the ttengine sources, I at least managed to get the first few pixels out of it:

These are some pixels of "Hello from ..". Yep, not perfect, but not bad either ;).

2008-01-07T15:48:00.000+01:00

And a time to move..
to our new house. We will start to pack today and to get everything into the new house during the weekend. Hopefully the weather will be better than today (raining..).

2007-10-17T16:28:00.000+02:00

There's a time to code..

and a time to do real work ;). Away from any keyboard. We bought a house for our family (not a cheap thing here..). As this house is now 25 years old, it needs quite some repairs and a lot of refurbishment. So I am on vacation for the next four weeks.

Btw, I fixed the bug of my previous post. But it was not the last one.. there is a problem in the entry widget, which needs to be fixed. But not now, I'll have to grab a paint brush now ;). cu.

2007-09-10T09:30:00.000+02:00

Infinite dreams I can't deny them
Infinity is hard to comprehend

There's a (bigger) problem hidden inside my sources. If you add an element to another, you can do that with gtk_box_pack. What I did, is just call ADD_MEMBER in the MUI side of things. But sometimes, a widget has an own add-method, which can also result in an ADD_MEMBER MUI call. So basically, I end up with the same MUI object added twice to one parent. MUI/Zune should really throw an error here. Gtk does at least, if you try to do such a thing.

I caused the problem, when I disabled the widget add functions for some widgets, but not for all. Now I have to enable all add-methods and remove the ADD_MEMBER calls from box_pack functions..

At least I now know, what's going on. I had to take a 2 weeks break from my sources and then I found the problem within 30 minutes. Before the break, I searched for 3 days without results..

2007-08-07T11:53:00.000+02:00

An now the same for gtk_hbox widgets ..

You can see in the screenshots of my previous post, that the "Change" buttons have the same horizontal size, as the input fields. The box layout in GTK differs from the MUI layout..

As adding the original table layouts from GTK to my mui objects went so well, I dared to add the GTK box layouts to the MUI boxes, too. This seems to be more difficult. Some times I get an infinite notify loop, which seems to be *very* difficult to find, at least for me.

If it works, it looks perfect:

The eject/insert buttons have the perfect horizontal size, the floppy leds, too. The input fields get as big as possible.

But there are those strange effects, if one hbox contains another hbox. Not always, but often..

2007-07-20T15:41:00.000+02:00

Troubles solved

Bughunting gets really difficult, if you have a lot of GtkWidgets nested and one calculates its size wrong. So finding that little error took longer than implementing the Gtk table calculations into gtk-mui. It's always the last 10%, which take up 90% of the time ;). But now it looks promising:

Even the page, which was the reason for all the effort, looks now (nearly) perfect:

You can now do homogeneous and not homogeneous tables, with elements covering more than one cell horizontally or vertically. Tables grow automatically, if you add rows/columns etc. Maybe I should make a custom mui class out of this.. but not now;).

2007-07-04T17:27:00.000+02:00

Trouble with tables..

After quite some break from coding, I wanted to clean up the sources and wrap a v2.0 label around them ;). For a final test I built e-uae with GTK gui again, and it had one big layout problem. I enhanced the table layouting, so that you could have both tables with homogeneous cells or not. Although this worked with my small test cases, it totally blew up with many nested tables :(.

So I did, what I should have done from the beginning. Look how GTK layouts its tables. Funny thing is, that in GTK you have the same basic methods as in MUI. You first do a MUILM_MINMAX to calculate the wanted sizes of your object and after that you reach MUILM_LAYOUT in which you are told, which space you got for your children and have to place them.

In GTK this is done through a size_request and a size_allocation. So I wanted to call gtk_table_size_request from MUILM_MINMAX and gtk_table_size_allocate from MUILM_LAYOUT. It compiled without problems, good to see, how close my environment is to the original. I had to patch gtk_widget_get_child_requisition, to send reasonable sizes of the table children to the size request and gtk_widget_size_allocate, which now calls MUI_Layout.

GTK doesn't have min, def and max size values like MUI, but this was trivial to fix by doing the size request three times with different child sizes (min, def and max).

I searched for a bug, of which I thought was inside the GTK stuff, but I just got the parameters for MUI_Layout wrong. The simplest Bugs are sometimes the hardest to find...

At the moment, tables work fine and look really good. E-uae looks better than before, but still has some (minor) issues with tables in frames.. So still something to debug left..

2007-04-10T11:57:00.000+02:00

Something private

Somebody told me, that blogs should also contain private stuff.. but in my job, data protection and privacy is my main issue. Nevertheless, here is a picture of my twins (and me) in Fuerteventura:

2007-03-20T15:56:00.000+01:00

Vacation

Me and my family will spend some time in the sun next week (Fuerteventura), so I am busy even more then normally (you have to pay every vacation before and after your vacation with more work..). So not much will happen in the near future. I have committed all my actual sources to the CVS, just in case the airplane will crash ;). Maybe Itix finds some time and looks at the sources, at least he commited two small changes last week, let's see.

2007-03-02T13:01:00.000+01:00

Harddisk #2

and it even seems to work ;) now:

But the Properties and the Remove buttons are not working ATM.

2007-03-01T17:51:00.000+01:00

Harddisks in e-uae ..

are coming closer ;). After implementing a first version of GtkClist, GtkScrolledWindow and GtkDialog, I was able to compile e-uae for AROS with GTK UI and autoconfig enabled. So now the GUI to mount host file systems inside e-uae can be launched:

There are still some bugs left (of course), but things are fitting together more and more. With every widget already existing, adding new widgets to GTK-MUI gets simpler . Itix tried to do GtkDialog long ago. He had to write a lot of custom code and it would have never been the real thing ;). With the current status, I could just take the gtkdialog.c/.h source and add maybe 10-20 lines to it, and it worked ;).

It's not always that easy, but here it was ;).

2007-02-21T10:48:00.000+01:00

e-uae again

As I read the quite interesting blog of rob about his DOS packet adventures, I felt guilty about no updateing my own blog. Btw, congratulations to Michal, as he has now a "Dr."-title.

So what's on in gtk-mui land?

A long time ago, I did a compile of e-uae with a gtk-mui gui. I was now curious, if e-uae still works..

Well, it didn't ;).

It crashed, as soon as I released the "Pause" button and such as life is, it was not really obvious, what caused that segfaults. If I comiled e-uae with my old version, everyting worked as expected. After some (!) debugging time, I found the bug in the e-uae sources. As I compiled without file system support, there was one ifdef, which caused some memory to be uninitialized.. something which went well with my old gtk-mui lib by accident.

Still there were random crashes. This did not cost much debug time. It seems as if the default stack size in AROS is not big enough, after setting the stack to 100k the crashes are gone. I have to investigate, how to increase the stack in AROS inside a program, as stackswap seems to be no help in AROS..

After all, e-uae works again, even the debug button now works perfectly (which did not work in the old version AFAIR). The only thing, which seems to be broken, is that the memory configuration is not saved. Well, it is saved in the prefs file .uearc, but it is not read back correctly. But this is not a GTK problem ;).

And here's a screenshot with e-uae running the Red Sector Megademo which shows the power led and the floppy led displayed correctly (custom gtk widgets) and the debugger in the AROS shell behind (and you can see one of the remaining problems, too, the string gadget should take all the horizontal space..):

2007-01-03T17:33:00.000+01:00

GtkMenu != Zune Menu ..?

Gtk Menus are more powerful, than Mui/Zune ones, so a perfect mapping for menus will be more than difficult (if not impossible ;)). In the old version, I tried to convert the GtkMenu Widget to classic intuition like menus at the top of the screen.

Looks nice, but in Gtk, you can have more than one menubar, which is not possible for intuition screens, of course. So I thought about an own aros menu for every gtk menubar, but as the depth of amigaos menus is more than limited, this was no option.

Now I switched to context menus. They are the closest thing to Gtk Menus, I could find.

A Gtk Menu example:

Here we have one menubar, containig two menus (actually just two text accel labels), which have a menu attached.

In AROS this looks like that:

The only problem remaining are submenus, which do not work at the moment. But it was enough work so far ;).

So our new Gtk Widgets are:
- GtkMenuBar
- GtkMenuItem
- GtkMenuShell
- GtkMenu
- GtkAccelGroup
- GtkAccelMap
- GtkAccelLabel

Gdk functions added:
- GdkKeys
- GdkKeyNames
- GdkEnumTypes

2006-12-21T15:54:00.000+01:00

Merry Christmas..

The usual Christmas business prevented me from releasing a v2.0 of gtk-mui, sorry. I will be on vacation until January the 8th and I am not planning, to touch a keyboard during this time ;). But it is quite likely, that I read my mails from time to time.

Back on topic: I managed to build freetype/fontconfig libs for AROS, but they are just crashing with the test programs. I had no time, to start debugging, but this will be part of v3.0 anyways ;).

What is still missing on my 2.0 agenda is menu support. It is implemented already, but needs quite some debugging, as always.

.. and a Happy New Year!

2006-12-04T13:06:00.000+01:00

Merged..

Finally I merged the two development branches, most widgets are working again. There are still some widgets, which are not yet converted to glib objects (handle_box menu, toolbar,grab and messagedialog), but the others (appr. 50 widgets) are converted.

It is now much easier, to add a new widget to gtk-mui. You can use the original GTK header and use most of the original GTK widget source. You just have to replace all widget displaying code with MUI calls. This might work without a custom class (tooltips for example) or might require quite complex MUI classes (spinbutton for example).

In GTK you have the following widget hierarchy:


GObject
 |  
 GtkObject
  +GtkWidget
  | +GtkMisc
  | | +GtkLabel

The further you go down the tree, the more properties a widget has. In order to be able to store MUI properties for every widget without having to modify the GTK headers, I added a GtkMui widget:


GObject
 |  
 GtkMui
 |  
 GtkObject
  +GtkWidget
  | +GtkMisc
  | | +GtkLabel

If you now want to be able to create a new GtkLabel object with


GtkLabel *label;
label=gtk_label_new("test");

you simply have to add the following to the widget init code in gtk_label.c:


GTK_MUI(label)->MuiObject = NewObject(CL_Label->mcc_Class,NULL,TAG_DONE);
set(GTK_MUI(label)->MuiObject,MUIA_Text_Contents,label->text);

You'll need the according MUI Label class of course ;).

2006-11-24T16:12:00.000+01:00

As you could see in the CVS, I am in the progress of merging GLIB_oli and MAIN. Most files are done already and most test cases work (again). But still not all required files are commited.. and a lot of files need to be removed, as they are now in the real glib directory.

2006-11-16T16:58:00.000+01:00

Just noticed, I did no updates for quite a while, sorry, as always ;). My Servers are up again (the cheap box died one week, after I got my new servers.. Harddisks are not really reliable these days.. I now have two servers with RAID controllers each, maybe I should place one in a different location..).

iconv.library

Up to now, gtk-mui, iconv and glib were static link libraries, which leads to quite big executables, even for small programs. So I try to understand, how AROS libraries work (or better, how to convert a unix link library to an amiga library). I managed to get an iconv.library, but the only thing it does, is to write core dumps.

gtk-mui

Long time ago, I created a branch in the CVS, so that I could test the glib integration. In the main trunk, itix made some MorphOS and other changes. For quite some time, I was not really motivated, to do the boring, but the necessary merge . I started merging yesterday and it seems, it's not too difficult. Most tests work with the new merged version, but there are still some problems remaining.

2006-08-28T15:05:00.000+02:00

glib 2.12.0

Itix updated the CVS glib from version 2.6.6 to version 2.12.0 some time ago. After adding a few patches, which, as it seems, I have forgotten to commit to the CVS, I can now also build a native AROS version of glib 2.12.0.

Why not more progress?

I had some bad luck with some of my servers. Having a second backup server is sometimes not enough, if within one week, both machines die because of hardware errors :(. My domain was down for some days and you could not reach me through my private E-Mail adresses. Everything is up and running on a cheap emergency box now, hopefully, this will not die, too, until I get new reliable hardware up. I had everything on backup tapes, so no data was lost, just a lot of time..

2006-08-03T12:00:00.000+02:00

e-uae-0.8.29-WIP2.aros-gtk

is now available as a beta (!) version from:
e-uae.aros-gtk.20060704-2.gz (readme)

Source is also there:
e-uae-0.8.29-WIP2.aros-gtk.src.20060719.tar.gz

I mailed this link to Richard Drummond, so hopefully some of my changes will show up in the main tree, as soon as he finds some time ;).

2006-08-03T11:39:00.000+02:00

gtk_notebook_set_show_tabs

During a debug session for "random crash bug" in the notebook widget, I got bored and decided to add a new feature, so now the widget can have tabs, as you can see here:

or can have the tabs switched off:

Of course, you can toggle the tabs on/off with the "tabs on/off" button in this example (in other words, gtk_notebook_set_show_tabs now works).

So my custom notebook class can be toggled between a RegisterGroup and a HGroup with MUIA_Group_PageMode=TRUE with a simple

set(GtkObj(notebook),MA_Show_Label,TRUE);
set(GtkObj(notebook),MA_Show_Label,FALSE);

And I finally found the mysterious and long annoying "random crash bug" in this damned widget, too ;).

Sometimes it is better, to add new features, instead of hunting down bugs..

2006-07-13T11:19:00.000+02:00

Well, I am still not used to this blogging stuff ;), so updates happen not too often, sorry.

But there is something new to see, it's e-uae WIP2 for AROS with a GTK-MUI gui:

E-uae can be built with normal configure and make (I will submit my changes to evilrich soon, promised). There are still some minor bugs left (radiobuttons are not updated with the previous saved values for example), but you can make changes to the config and start uae. You can swap disk images. And after a long bug hunt, you can now even close uae with the quit buttons ;).

This build was done with my glib 2.6.6 (now also in archives.aros-exec.org) and with GTK-MUI build from the GLIB-oli branch.

What's left for a GTK-MUI upload to archives is the merging of the two development branches, which is still to be done :(.

So, what can you do with GLib/GTK-MUI at the moment?

(this is quoted from my mail to teamaros)

GTK-MUI(zune) is based on top of GLib (not necessarly on my GLib port,
it should work with every GLib port for example on AOS4/morphOS).

GTK-MUI offers a lot of GtkWidgets(but far from all), which
are more or less complete compatible with their real GtkWidgets.
So if your GTK app uses only existing GTK-MUI widgets (and only
implemented methods of those widgets) it should be a simple job
to port the app. In that ideal case it might be enough to run
configure and make ;).

The real world looks different, as there are a hell lot of
GtkWidgets and every widget has a hell lot of methods ;).

In GTK-MUI, MUI (zune) does more or less the job of GDK, it
renders the gadgets and sends the signals. So not many GDK funtions
are implemented at the moment. If you app relies a lot on GDK,
it will get difficult. Also pango (the GTK text rendering engine)
is still missing completely. Might be the next big step to
port that, not impossible to do it the GLib way. Freetype
lib should be available on AROS, as far as I have seen, but
pango also requires fontconfig, this is not on AROS or am I
wrong?

Custom GtkWidgets (equivalent to private custom classes in
Zune) do work in GTK-MUI, the less they depend on GDK, the
better;).

2006-03-21T15:43:00.000+01:00

Well, everybody seems to need a blog, ok, that's mine. I'll try to keep you updated here on GTK-MUI mainly, let's see, if it works ;)