@Spirantho

But not everyone in the MorphOS team works on drivers, fortunately. Several other core developers contribute on higher level components such as dos, filesystems, datatypes, reggae, intuition, mui, applications and whatnot.

I agree driver work can be quite tedious, but it would seem it's also a burden for OS4 as well... Let's think about yet to be written audio drivers, 3d, overlay and several other things for well documented hardware.

Regarding Macs, they may be old, but they still deliver a performance close to the X1000 in several areas, are 10x times cheaper and can still be repaired and found in large quantities.

@mrodfr

Even if OWB uses software cairo rendering, it only renders (and blits) the damaged areas instead of the whole page each time a change occurred, which is of course infinitely more efficient in the case of a blinking cursor, for instance.

This is a bug in the fontconfig OS4 port, to be exact.

Quote:

While it's true the old 1.9 version was using 1 as codeset, i was still set BEFORE. No idea why you get it after on OS4.
Unicode to local charset copy could be done manually at that time, by using pulldown menu -> copy with local charset (or so).

Anyway, all this is irrelevant, because i've reworked UTF8 clipboard management since quite a while in OWB.

Now, when copying, i store the first chunk as ID_CHRS (with data converted to local charset), and the second as ID_UTF8 (which is not 1, but no idea if it's the same value as OS4).
When pasting to OWB, the ID_CHRS chunks will first be tried (and converted from local charset to UTF8) and if ID_UTF8 chunks are found, they'll be used instead.

Other MorphOS applications work that way, and it behaves just nice.

As for input, OWB for MorphOS uses MapRawKeyUCS4() to handle input. I guess only the MapRawKey() fallback was used on the OS4 port. If there's anything similar in OS4 API, kas1e should make use of it to handle unicode input.

Not exactly sure, but it's caused by the use of these quotes, at least.

Well, the black area can be ignored here, it's replaced with HTML5 video tag when supported.

As for the links below there are two kinds: the ones you click to play in the html5 player (view ...) which should of course be ignored too, and the download links which are the ones you're interested in.

So configure owb mimetypes -> video/mp4, video/webm, etc... to an external (or ask) action, and when clicking these links, a requester/player/whatever you configured will appear.

To be noted that Youtube sometimes advertises non available formats, too. But 18 (640x360 H264) should be available almost always, in any case.

@kas1e

From Jacek:

The price is not negotiable. PowerTerm is a seasoned, widely used and tested product. It's in active development for almost 10 years. Countless workhours were spent on making it compatible with xterm, fast and portable.

Well, no need to contact him, here's the answer from Jacek:

MUICON is a MorphOS program and is not going to be ported to any other OS. Opensourcing is out of question since it relies on MorphOS internals and is in part based on work of other MorphOS Core Members. PowerTerm.framework(mcc) however is a commercial product which can be licensed to 3rd parties. I am willing to consider a closed source port for 8k euro or handing the sources to a 3rd party (under a closed source license) for 10k euro. These conditions would be exactly the same to consider an AROS or AmigaOS 3.x port. Please send any questions related to PowerTerm to iconsole@iconsole.pl

@Antique

First, since Clipdown only relies on clipboard monitoring, and that clipboard obviously works in OWB, it's no problem.

Then, there's no need at all for ClipDown (nor even GetVideo, if you use Youtube.js extension/userscript).

You just need to configure OWB contextmenu entries to call Getvideo, that will itself call MPlayer (it's explained precisely in GetVideo's readme).

And if you don't want to use GetVideo, just get http://fabportnawak.free.fr/owb/scripts/YouTube.js and add it through menu ->windows -> userscripts in OWB.
Once done, when loading a youtube page, the extension will add direct links (for each found format) below the video area. On MorphOS, it would also replace Flash with HTML5 video and play it directly. On OS4, since there's no builtin HTML5 player, you can still configure OWB mimetypes (video/mp4 video/webm video/x-flv in this case) and tell it to call MPlayer when clicking this kind of file.

Quote:

And

Quote:

Being 3.5x times as slow as what the chip could normally allow is quite a problem to me, if you ask me. :)

And I don't know Doom 3 in particular, but with Quake 3, CPU/Memory speed also had a great impact on the final benchmarks (like 48fps on Peg2 vs 76fps on Mac mini). But maybe it's less true with Doom3, which i imagine should rely more on GPU, but that's just a wild guess, it might also be very CPU hungry too.

Which you can do by using contextmenu over list column header and checking "password" column. But maybe this contextmenu over list header (and HIDDEN attribute for columns) doesn't work in MUI for OS4.

I completed RTCW on Peg2/MorphOS more than a year ago, and it was really more than playable in most places, the exception being a couple large outdoors scenes where fps could go down to about 10fps, but fortunately, there weren't that many places.

@abalaban

I don't think it's relevant to consider receiving mailouts from large projects automatically means you're a very very very busy person.

By being subscribed to webkit, mplayer, scummvm, morphos & co, i receive hundreds of mails per day, but that doesn't mean anything, really.

@Raziel

It's fixed since one year in WebKit (and thus OWB MorphOS). But the port of MUI OWB you have is based on OWB MorphOS 1.9, dating from august 2010, which is why you have this bug.

This image lazy loading thing at google image, youtube and this site is a regression in WebKit that was fixed about a year ago (between r66666 and r71312 from what i can remember).

The PDF export function in OWB MorphOS reuses a generic WebKit method (and by the way, you can choose to disable background by unchecking the "Print backgrounds" option in prefs->content).

The problem is i currently don't compute a proper resolution/DPI for the PDF export. The width isn't really suited for A4 printing (or anything else). Ideally i should also show additional export options (page number, DPI, ...).

As for the window.print() binding, it would surely be trivial to add, and it would also be even easier to add a PRINT REXX command (actually it already exists, it just does nothing).

@Deniil

Quote:

I wonder how they achieved so poor results then.

On a MacMini G4, H264/WebM 360p playback in WebKit/OWB takes about 80% cpu in plain cairo image surface mode (most of the time being spent in cairo), and 20% when using overlay mode. And FireFox/TenFourFox on OSX surely has some kind of HW acceleration for Cairo, so there's really no excuse...

Changing the port name doesn't make much sense, just as using the two OWB flavours at the same time doesn't.

As for the ASL requester, it's definitely a difference in behaviour in MUI OS4, because here, it always opens on the screen it was called on. Of course, you can always force it to whatever screen you want with additional tags, but it shouldn't be needed here.

And yes, the requester is synchronous (with a bit of work, it could be made asynchronous, but it's less trivial than it sounds, because you would need to wire that to some webkit events as well). But in any case, the application (and thus all subwindows) are explicitely set to sleep, currently, so they should really show the busy pointer.

As for the random crashes when downloading images, they're definitely specific to OS4, and i really fail to see what could happen there, actually.

And a bit off-topic: all these issues with MUI getting suddenly small/unreadable fonts is in my opinion related to the tabs and/or URL poplist having too long titles/URLs.
In OWB MorphOS version, the tab title is truncated if needed, and MUI4 lists have an horizontal scrollbar. Too long items won't cause any kind of layout issue, which is apparently not the case in MUI OS4 list. If that's the case, it will be trivial to manually truncate the offending URL/titles (there are functions for that in my API if needed).

@DAX
More like a corrupted gmail cookie. You can delete conf/cookiedatabase.db and try again.

@JosDuchIt

Help and SaveURL (and the others) REXX commands work just fine in the MorphOS version, so it has to be something wrong in the OS4 port.

As for the Reaction OWB commands, i don't plan to support them.