Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
110 user(s) are online (64 user(s) are browsing Forums)

Members: 0
Guests: 110

more...

Headlines

Forum Index


Board index » All Posts (joerg)




Re: Assigned project: Graphical Common Download Manager
Just can't stay away
Just can't stay away


@DaveP

Quote:
Presumably you can pass a socket descriptor.
No. I could pass a pointer to the OWB ResourceHandle object, which requires rebuilding the download manager for new OWB versions if something changes in it, or maybe a libcurl handle, but nothing more low level. In any case it couldn't be a general download manager any more but would be one which only works with OWB, and for something like that it wouldn't make any sense to create an external download manager since it would be much less work to implement it in OWB itself.

To pass a C library, or a bsdsocket.library, socket descriptor from OWB to a download manager someone would have to reimplement the OWB/WebKit network code using C library, or bsdsocket.library, sockets first. But without using a library like curl or soup that would be much more work than implementing a download manager in OWB as well ...

Go to top


Re: Assigned project: Graphical Common Download Manager
Just can't stay away
Just can't stay away


@Hans

Quote:
Looking at the server logs of my website, OWB seems to use WGet for file downloads, which won't work with files that require authentication.
OWB doesn't use an external tool like wget for the downloads.

What's currently not supported in the AmigaOS 4.x port of OWB (except for version 3.8) is sending cookies set by JavaScript, and that's very likely the reason for your problems. For the next version I've removed the AmigaOS 4.x specific cookie changes, OWB's own cookie support finally seems to work with most sites. There may still be some problems, but I guess more will work that way than with OWB <= 3.15.

Go to top


Re: Assigned project: Graphical Common Download Manager
Just can't stay away
Just can't stay away


@DaveP

Quote:
OWB can't send a request on a message port or call a library?
It would only work for downloading from sites like os4depot, aminet, etc., which don't have any restrictions, but on sites like rapidshare.com even passing the cookies and referrer to the download manager doesn't help since you can't download the same link twice, but that's what would happen with an external download manager (the browser starts the transfer, detects it's a download, aborts it's own transfer and passes the data to the download manager which starts the download again but only gets an error from the server instead of the file).

Quote:
Anyhow, the source is completely open, so when its done, it can be integrated with whatever.
Integrating a general download manager in OWB would probably be as much work as implementing an own one from scratch, and a lot of the download manager code, for example everything network related, would be useless.

Go to top


Re: Assigned project: Graphical Common Download Manager
Just can't stay away
Just can't stay away


@DaveP

Quote:
Its just about downloading files for browsers like OWB or NetSurf, not about keeping software up to date.
It can be a replacement for old download managers like HTTPResume, Charon, etc., but an external one can't be used by browsers like OWB.

Go to top


Re: OWB better than FireFox!
Just can't stay away
Just can't stay away


@Fab

Quote:
This is about WebKit (and its graphics/fonts/... backends) being compliant... Sandlabs or OWB porters don't have much to do with that result,
The AmigaOS port of OWB doesn't use one of the WebKit or OWB font implementations but an AmigaOS 4.x one I implemented myself and for example at the time I added it support for text shadow, which is required for the ACID3 test as well, it didn't exist in the other OWB font implementations yet.

Quote:
(IIRC the only fix I had to do to reach 100 was to fix the base64 decoder).
You should check again what you copied from the AmigaOS 4.x parts
(Could be that I added some of the bugfixes to the SVN outside of #if PLATFORM(AMIGAOS4) parts, though.)
There was not only one bug but 3 bugs I had to fix to get 100/100, the broken base64 decoding was only one part of it. Additionally it didn't skip non-printable chars (CR, LF, spaces, etc.) in data: URLs correctly, and it used a wrong encoding somewhere. Only after fixing all 3 bugs OWB reached 100/100 instead of 98/100 (only the Gtk port got 100/100 earlier since it's using some glib functions instead). IIRC one of these 3 bugfixes was only required in old versions and got obsolte with some WebKit merges about 6 or 9 months ago.

Go to top


Re: Increasing OWB font sizes
Just can't stay away
Just can't stay away


@jahc

Quote:
EDIT: you may need to use these settings in your Typemanager prefs? click on the font, then click modify, then choose the Hinter..
http://wookiechat.amigarevolution.com/problem/hinter.png

EDIT2: Ah, amigaworld.net uses Arial which looks not as good on my setup with FONTHINTER=1 .. I need to play with it some more.
To use the font hinters configured in TypeManager you have to use FONTHINTER=0 in OWB.
That way you can use different hinters for the different fonts, and since it depends on the font which of the 4 hinters looks best you have more control that way, for example you can use another one for Arial.

With FONTKERNING enabled the texts look better, but since text input doesn't work correctly with it, the cursor is often at the wrong offset (not only with my AmigaOS 4.x OWB font implementation, it's the same with the libfreetype one), it's better not to enable it.

Go to top


Re: OWB 3.15
Just can't stay away
Just can't stay away


@MickJT

Quote:
You said OWB doesn't have a GUI... What are these back/forward buttons that I see?
I've added them in the AmigaOS 4.x version of OWB, the 3 other ones (SDL, Gtk and Qt) don't have a toolbar nor any other GUI elements.

Quote:
If you can add a bookmarks feature,
The "OWB GUI" bookmark used by the AmigaOS 4.x version of OWB was implemented by George Sokianos.

Quote:
then you can add a download manager, or at least a progress bar.
Of course I could do it if I would have the time for it, and implementing a download manager is very easy, but I don't consider it an important feature. There are browser independent download managers for AmigaOS which can be used instead and a lot of more important browser features missing in OWB which can't be replaced by external tools.
OWB is free, open source software and like with any such software your options if you want to have a feature which doesn't exist yet are
- Implement it yourself.
- Pay someone to implement it for you.
- Wait until someone else does one of the above for you.

Go to top


Re: OWB 3.15
Just can't stay away
Just can't stay away


@kas1e

Quote:
I am not so in business, but maybe porting of morphos download manager will be more or less easy ?
That's impossible since the MorphOS port of OWB is not open source. But even if the sources would be available they would be just as useless as the AROS ones, about 90% of the code for a download manager is GUI related and the MorphOS one uses MUI4.

Go to top


Re: OWB 3.15
Just can't stay away
Just can't stay away


@jahc

Quote:
Are the makers of OWB (not the porters) working on optimising the base code as they go along?
Sometimes there are optimizions in OWB parts as well, and some of them were taken from my AmigaOS 4.x port, but most of the improvements are from WebKit and not in OWB parts.

Quote:
It's interesting, as Joerg is updating to the latest svn on a regular basis, and it seems to be getting faster and faster.. maybe both Joerg AND the core OWB developers are doing a little optimising?
AmigaOS 4.x specific optimisations are mentioned in my release notes, for example in version 3.11 ("Changed rendering method ...").

Quote:
It's just getting better and better, and then a tiny bit worse, and then better again, as we go along. :)
Always using the current OWB SVN sources, and therefore current WebKit as well, adds all improvements from OWB and WebKit, but sometimes it adds new bugs as well ...
Even if that sometimes results in AmigaOS 4.x versions of OWB with a lot of new problems I don't notice myself before releasing a new AmigaOS 4.x version it's IMHO better than not updating the OWB sources, although that would make it much easier to add new AmigaOS 4.x features.

Quote:
Rendering is very impressive, youtube plugin will be here soon, but I reckon there's a lot room for improvement speedwise, considering its based on Webkit.
There was a lot I did optimise in the AmigaOS 4.x port of OWB, but I very much doubt there are any more major speed improvements possible.
Except for adding PPC support to the JavaScript JIT, currently it only supports x86 and ARM, but I wont do that. It's not only way too much work for me, someone who knows PPC assembler would have to do it.

Quote:
Webkit == zoom! On my Sam, the speed is usable though, and for now thats good. :)
It's "zoom" on the SAM as well, at least the AmigaOS 4.x version of OWB, if you compare it with slower browsers like IceWeasel (FireFox) running on Linux on the same hardware
The AmigaOS 4.x version is much faster than the SDL, Gtk and Qt versions of OWB, and IMHO it's faster than all other WebKit based browsers I tested on Linux (Epiphany-webkit, Arora, ...) on my A1 as well.

Go to top


Re: OWB 3.15
Just can't stay away
Just can't stay away


@kas1e

Quote:
btw, just in interest: have core developers in plans add download manager ?
How should a download manager be possible without a GUI? OWB has no GUI at all.

Even if they would implement a download manager for example for the Qt version of OWB it would be completely useless for all other versions of OWB (SDL, Gtk, AmigaOS 4.x, ...), just like adding the AROS Zune download manager, which isn't in the OWB SVN (yet?), would be useless for the SDL, Gtk, Qt and AmigaOS 4.x versions of OWB.

Go to top


Re: Ftp server
Just can't stay away
Just can't stay away


@Raziel

Quote:
Funnily enough ONLY the ftp command from C: can log into and use the ftp pages of my router (all others seem to rely on a given username (which the router doesn?t want, it only asks for the password - i *think* it?s using "ANONYMOUS" for the username, but i?m not sure, as typing that in AmiFTP gets me nowhere)
If you don't specify a username the one C:ftp uses is usually the UID 0 one from DEVS:Internet/users, if you didn't change it "root", and it's displayed after the host name ("Name (server:username):") when it asks for it. Try that in the GUI ftp clients.

Go to top


Re: OWB3.14
Just can't stay away
Just can't stay away


@broadblues

Quote:
It's really annoying! Spoofing in AWeb makes no difference, can you spoof a different browser in OWB?
Yes, by setting the OWB_USER_AGENT environment variable (you have to quit and restart OWB after setting/changing it).
To test the user-agent the next AmigaOS 4.x version of OWB will use, which for example fixes the broken MicroSoft site, use
Quote:
SetEnv OWB_USER_AGENT "Mozilla/5.0 (compatible; Origyn Web Browser; AmigaOS 4.1; U; en) AppleWebKit/531.0+ (KHTML, like Gecko, Safari/531.0+)"
in a Shell before starting OWB.

Testing something for the forum post problems ... fixed

Go to top


Re: OWB3.14
Just can't stay away
Just can't stay away


@xenic

Quote:
I can't get the forum submit button to work right either.
I just tested it with r1006 of OWB and it still doesn't work
I've fixed a few problems in the AmigaOS 4.x parts, for example the scrolling bug, but as long as javascript based forum posts like the amigans.net one don't work it probably doesn't make much sense to release an update and I'll wait until it's fixed in WebKit or OWB again.

Go to top


Re: OWB3.14
Just can't stay away
Just can't stay away


@Hans

Quote:
Maybe you should suggest a bounty for a Javascript JIT. Google's V8 Javascript engine or Firefox's Tracemonkey could be candidates for a starting point.
Why V8? Since it doesn't support PPC either, only x86 and ARM, WebKit's own JIT, SquirrelFishExtreme, would probably be the better choise.
For TraceMonkey there is some (incomplete?) PPC support, but integrating it in WebKit is very likely much more work than porting the x86 parts of SFE to PPC.

Go to top


Re: pthread
Just can't stay away
Just can't stay away


@Kicko

Quote:

Kicko wrote:
@joerg

If i do a search for threads.library in SDK for os4 i see these files needs it.

sdk:Local/C/perl
sdk:Local/C/perl5.8.5
sdk:Local/newlib/lib/libpthread
SDK:Local/newlib/lib/libpthread.a and libpthread.so use pthreads.library, not threads.library. If you have versions using the ancient threads.library installed you overwrote the ones included in the SDK.

Quote:
Can i just delete the threads.library or do i still have to use it ?
If you need software which still uses threads.library like perl and there is no replacement using pthreads.library yet you can't delete it.

Go to top


Re: pthread
Just can't stay away
Just can't stay away


@ssolie

Quote:
@joerg
Quote:
It's even worse if you run old software using threads.library and new software using pthreads.library or libpthread.so at the same time.
Can you elaborate a bit on the underlying problem? How do they trample each other?
AFAIK both use the same pointer in struct Process for their own thread data.

Go to top


Re: pthread
Just can't stay away
Just can't stay away


@Chris

Quote:
Software linked with the old pthreads needs threads.library. Of course it's OK to install this for existing apps
No, it's not. The old threads.library doesn't work (not sure if it ever did without problems, at least it doesn't with current versions of AmigaOS 4.x) and you may get random crashes. It's even worse if you run old software using threads.library and new software using pthreads.library or libpthread.so at the same time. You should send bug reports to the deveopers of programs which still use threads.library instead, all they have to do is to rebuild the software with a current SDK, changes in the code aren't required.

Go to top


Re: OWB 3.13
Just can't stay away
Just can't stay away


@broadblues

Quote:
In my case I renamed the .otag file for tahoma to _tahoma.otag to prevent it's use as I new it was broken, (yet leaving there to remind me to fix it at some point)...
Renaming .font/.otag files doesn't disable them, to remove a font from the system you have to move the files out of FONTS: into another directory.

Quote:
I notice that OWB scans every font in the FONTS: directory, even though you are trying work arroung the absense of fonts or the misnamedness (sic) of .otags files is that really a good idea?
It has to be done because of the wrong .otag files (without the font families set, which has to be done manually as TypeManager doesn't do it automatically when installing fonts) a lot of people are using.

Quote:
At the moment my A1 font directory is relativly sparse but my old A1200 directory was a lot fuller, scanning fonts in this way is going impinge on prgram startup time somwhat I would think.
It only opens outline fonts (fonts which have both a .font and .otag file), not bitmap fonts, and unless FONTS: is on a slow FFS partition and you have hundreds of fonts installed it shouldn't cause a noticable slowdown.

Quote:
When you scan the "broken" .otag files I would suggest the next step would be to check the .ttf file pointed to exists.
The next version will do that, but of course opening the .ttf (or .pfb/.afm) files additionally to the .font and .otag files will make it slower ...

Quote:
Or maybe just publish a list of .ttf files that must be in FONTS:__truetype and let the user sort it out.
The only fonts required by OWB are the DejaVu fonts included in AmigaOS 4.x, everything else, like the web core fonts most websites are using, is optional.
But if additional fonts are installed which are used by a webpage they have to be installed correctly and work.

Quote:
It seems like you are using the font directly amyway, to get access to the full character set.
OWB doesn't access .ttf files (or the ones of other formats) directly, it uses the diskfont.library functions, for example if you just have a .ttf file without the .font and .otag files created by TypeManager it can't be used by OWB.

Go to top


Re: OWB 3.13
Just can't stay away
Just can't stay away


@Mrodfr

Quote:
hum. not 404 but 401 this time. Is it a feature implemented on OWB allready (log+password) ???
No, OWB doesn't support it.
But I've implemented it for the next version of the AmigaOS 4.x port.

Go to top


Re: OWB 3.13
Just can't stay away
Just can't stay away


@Jurassicc

Quote:
Yes, It happened since 3.10 IIRC Its in the OWB bug tracker.
I can't reproduce it. Not with OWB 3.10, which still needed correct .otag files, nor with 3.13. It's working correctly with the core fonts installed and I just deleted all fonts but the DejaVu ones for testing and it's working correctly without the core fonts as well.

Without an archive of your, very likely broken, FONTS:#?.(otag|font) files, the output of "list FONTS:_TrueType" and the OWB Tooltypes you are using it's impossible to reproduce.

Quote:
I think it has something to do with the OWB TTF fonts as I've got them installed on the A1, but not on the A1200 with OS4. It doesn't seem to happen on the classic.

--edit--

Just deleted the corefonts on the A1 using typemanager and it made no differnce. login elements are still too small with no visible text in them.

Yet if I copy the same OWB folder over to the classic it works ?
OWB 3.13 doesn't need correct .otag files any more and builds the font families itself now because to much people use broken .otag files.
It doesn't have workarounds for even more broken font installations like renamed .font/.otag files and I'll try to add some more workarounds, but I can't add checks for all possible font installation errors.

Go to top



TopTop
« 1 ... 46 47 48 (49) 50 51 52 ... 86 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project