Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
34 user(s) are online (16 user(s) are browsing Forums)

Members: 0
Guests: 34

more...

Headlines

Forum Index


Board index » All Posts (joerg)




Re: Web browser by Hyperion - feasible?
Just can't stay away
Just can't stay away


@Hans

Quote:
@Joerg

Have the AWeb guys ever contacted you?
No.

Quote:
IIRC, the plan was to create a new AWeb built around the KHTML toolkit (i.e., webkit). I have no idea how easy/hard it would be to rip out its display engine and replace it with OWB's core, but it is an idea.
If you'd do that the only parts of AWeb still usable would be some small parts of it's GUI (not the menus or anything else depending on it's ARexx port), the cookie handling and it's network functions (incl. memory and disk cache with cache browser), but that's something you definitely don't want to use, the only old AmigaOS browser with usable network support was Voyager (but the rest of it had way to much bugs), Voyager supports persistent HTTP 1.1 connections, AWeb and IBrowse don't but open a new connection for each request which is very slow.

Go to top


Re: Web browser by Hyperion - feasible?
Just can't stay away
Just can't stay away


@corto

Quote:
For internet browser, OWB was designed to be portable. So let's go, Joerg did the right choice, avoiding to spend months understanding internals of a browser engine (it may be the case though).
You don't have to understand the internals for a FireFox port either. OWB is portable (using SDL it runs everywhere without any changes) and you immediately get something usable and can implement the missing parts one after another, but unlike FireFox it's not a complete browser and you have to implement a lot yourself.
An AmigaOS 4.x port of FireFox port is less work than creating a complete browser from OWB, the only problem is that for a FireFox port you have to work for some months porting all the libraries it needs to AmigaOS without getting anything usable. Working on improvements of an already usable browser like OWB is much more fun

Go to top


Re: Web browser by Hyperion - feasible?
Just can't stay away
Just can't stay away


@RacerX

Quote:
Would it be feasible for Hyperion's programmers to develop their own OS4 specific web browser?
No. Even multi-billion companies like Apple, Google, Nintendo, etc., don't try to do something like that but use existing engines (Apple and Google: WebKit, Nintendo: Presto) for their browsers (Safari and iPhone, Chrome/Chromium and Android, DS browser and Wii internet channel).

Quote:
They, of course, know OS4 better than anyone. It should be faster and work better than ports of browsers designed for other systems. If they all worked together on it maybe it wouldn't be too huge of a project.
If both full time OS4 developers would stop all other AmigaOS related work I guess they could complete an AmigaOS browser created from scratch in about 20-30 years. But only a browser comparable to the current 4 major engines, not something which will be usable when it's completed ...

If they'd port Mozilla/FireFox instead it would take at most 3-6 months.

As long as I'm working alone in my spare time on it I guess it will take about 5 years to create an AmigaOS 4.x browser comparable to FireFox, Opera, etc., from OWB. Unlike FireFox OWB isn't a complete browser but basically "just" a portable version of the WebKit engine and I have to implement a browser around it myself.


Edited by joerg on 2008/10/26 4:40:25
Go to top


Re: OWB splash window
Just can't stay away
Just can't stay away


@salass00

Quote:
If someone makes the splash image I can write the launcher.
Mason created one for OWB:
Resized Image

Go to top


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


@redfox

Quote:
Just out of curiousity, I was wondering if there is a tooltype option available in OWB 2.12 to use my regular Workbench pointer like OWB 2.11 does right now.
Simply delete Resources/pointerCursor.info


@nubechecorre

Quote:
Do you know if OWB make use of virtual memory if enabled ?
AmigaOS 4.x always used virtual memory for (nearly) everything. If you mean paging: Like all programs using newlib.library all memory allocated with malloc(), new, etc. by OWB, i.e. everything but the memory for the executable itself, the windows and gadgets, stack, ..., can be paged out.

Go to top


Re: OS4.1 SWAP partition question
Just can't stay away
Just can't stay away


@R-TEAM

Quote:
[mmh ... An good U2SCSI driver with an good Seagate
HD and 80MB/s continous transfer speed on an 2-channel
SCSI card ...
Why do you want to use extremely expensive hardware, for which very likely nobody will ever write a driver for AmigaOS 4.x, just to get about the same speed you even get with the cheapest SATA drives?

(Not on an AmigaOne, there you get only a little bit more than 40 MB, but for example on a SAM440).

Quote:
-dream- > actual High-End SAS HD`s get 180MB/sec peek
Since both the AmigaOne and SAM440 only have PCI33 slots (the A1 has a PCI66 one, but at least a sii3114 controller doesn't work in it) it's impossible to get such speeds, you'd need at least PCI66 or better PCIe.

Go to top


Re: OS4.1 SWAP partition question
Just can't stay away
Just can't stay away


@R-TEAM

Quote:
the access and file transfer is on the outer sectors
faster.
Unless you use an at least 10 years old HD it doesn't matter at all on the AmigaOne because of the very slow PCI IDE DMA transfer speeds (about 45 MB/s max.), even the cheapest HD is much faster on the slowest part than that.

Go to top


Re: Battle for Wesnoth OS4 port
Just can't stay away
Just can't stay away


@ZeroG

Quote:
There is 1.5.20 in the list of unstable snapshots, should we use this, or another version?
Best would be using the includes for the correct version, but if you want to use something else use older includes, newer ones may have functions which aren't in the OS 4.1 port yet.

Quote:
Which version of pixman?
0.11.1

Go to top


Re: Battle for Wesnoth OS4 port
Just can't stay away
Just can't stay away


@ZeroG

Quote:
It is possible, but...

pango needs cairo, and the cairo developer files are not in the current SDK.
cairographics.org
The AmigaOS 4.1 port of Cairo is version 1.5.21.

Go to top


Re: Subprocess launching and communication.
Just can't stay away
Just can't stay away


@krashan

Quote:
I have another question. Does subprocess entry point function need some compiler flag like '__saveds' on 68k? I get some near-zero read hits when accessing globals.
There are no such compiler flags, if you build your program with -msdata you have to copy r13 from the parent to the child yourself (r2 if you use -mbaserel).

Go to top


Re: override default c:copy buffer
Just can't stay away
Just can't stay away


@xeron

Quote:
I wouldn't use 100000. Best to use 65536 or 131072 for optimum speed.
That's more important for the buffer size tooltype of ASyncWB since it's using bytes and doesn't round them, in C:Copy it's not bytes but number of blocks and therefore never can be a buffer size which results in partial block accesses.

Go to top


Re: Sourcecode for abandonware
Just can't stay away
Just can't stay away


@Skinner

Quote:
In any event, I know it's not open-source, but I thought if the copyright had been abandoned that the source may be floating around the net somewhere.
Are there really old commercial Amiga games for which the copyright was abandoned?
In a lot of countries that wouldn't even be possible any way, but what you usually get is just the right to downloads the old games from the homepage of the owner and use them for free, for example Cinemaware games, or another site got a licence to make them available for download and use for free, but of course that doesn't mean the owner gave up any other rights, for example in nearly all cases even redistributing them isn't allowed but only downloading them directly from the homepage of the owner, or from another site which got a licence from the owner for that.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just can't stay away
Just can't stay away


@Wanderer

Quote:
Yes, OS4.1 might have scaling for icons, as well as AfA OS 4.2 does.
But what's the use of it if you are an app programmer?
Do you want to limit yourself to OS4.1?
AmigaOS 4.x, icon scaling was supported by the AmigaOS 4.0 icon.library already, AmigaOS 4.0 just didn't use it itself yet like the AmigaOS 4.1 workbench does.

Quote:
I don't want to cause a flame war now, but I like my apps run everywhere.
For that you either have to implement everything 4 times, especially the GUI parts (AmigaOS 4.x ReAction, MorphOS MUI4, an AROS GUI for AROS, and either ReAction if you only want to support AmigaOS 3.5+, but still different to the AmigaOS 4.x ReAction GUI because of missing features and bugs in the old AmigaOS 3.5/3.9 classes, or even something completely different for AmigaOS 3.0+), or you only use the common AmigaOS 3.1 API and it's crap everywhere (gadtools GUI, no support for charsets other than ISO-8859-1, no mouse wheel support, etc.).

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just can't stay away
Just can't stay away


@orgin

Quote:
Dunno, perhaps the composition engine (cairo) of OS4.1 already can do all of the stuff mentioned here. Or at least should be used for something like this.
It doesn't matter if graphics.library, Cairo or another library like the one proposed here is used for scaling the images, adding computed effects, etc., for a GUI such low level graphics functions are useless, you need an image class which supports these features and can be used as replacement for the current image classes (bitmap.image, etc.).
Such an image class can use Cairo or toolbar.library internally, but they can't be used directly in BOOPSI GUIs.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just can't stay away
Just can't stay away


@Wanderer

Quote:
Like (peudo Code)

LoadBitmap(TBImages:cut24x24);

or

LoadIcon("MyIcon.info",24,16)

would load the icon in the specified (maximum-)size.
You, as the application developer dont care about it's actual size.
This is very handy for toolbars and everywhere you display Icons, when you want to force them to have uniform sizes.
On AmigaOS 4.x it would only add the scaling for images, not for icons since icon.library does support scaling icons itself. It's used for example in the new AmigaOS 4.1 Workbench text mode.

Quote:
So I decided to put it into a library. But if MUI and Reaction access the images by themselves, this only has a benefit if you need the resizing and/or effects.
For both it would have to be a BOOPSI image class. Although you can use old style struct Image images as well they have several limits, they are not only at most 8 bit palette mapped ones without alpha but a struct Image is of course only a single image and even if you can add 3 different struct Image images to a button like for example in buton.gadget (BUTTON_RenderImage, BUTTON_SelectImage and BUTTON_DisabledImage) it's still incomplete compared to a single image class image which can have more states, which you could compute from a single source image:
IDS_NORMAL
IDS_SELECTED /* for selected gadgets */
IDS_DISABLED /* for disabled gadgets */
IDS_BUSY /* for future functionality */
IDS_INDETERMINATE /* for future functionality */
IDS_INACTIVENORMAL /* normal, in inactive window border */
IDS_INACTIVESELECTED /* selected, in inactive border */
IDS_INACTIVEDISABLED /* disabled, in inactive border */
IDS_SELECTEDDISABLED /* disabled and selected */

Using a 32 bit ARGB struct Bitmap returned by your library with the bitmap.image class and the image created by bitmap.image in a button.gadget would make it possible to use true colour images with alpha, but it wouldn't solve the problem of the additional states, bitmap.image is limited to 3 sources for 3 states (BITMAP_BitMap or BITMAP_SourceFile, BITMAP_SelectBitMap or BITMAP_SelectSourceFile and BITMAP_DisabledBitMap or BITMAP_DisabledSourceFile) as well.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just can't stay away
Just can't stay away


@Wanderer

Quote:
The idea is to complete AISS by having an interface to access the images. Not everybody is firm in laoding and blitting images with alpha channel.
Of course you don't have to do anything like that yourself in any of the usual AmigaOS GUI systems (ReAction, MUI, Feelin, ...). It would only help in programs not using a GUI system but manually drawing something in a window instead.

Quote:
The library provides scaling and caching, so that two programs won't load the same images 2 times.
At least on AmigaOS 4.x it would only add scaling, and maybe computed effects for the selected and ghosted images instead of loading 3 separate images, but not caching since the intuition #?BitMap(Source|Instance)#? functions used by classes like bitmap.image cache the images and share them between multiple users already.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just can't stay away
Just can't stay away


@Wanderer

Quote:
The interface works like this:

aissbutton aiss_Open("TBImages:cut",width,height);
aiss_Blit(button,state,x,y,RastPort);
aiss_Close(button);
With such a low level interface it would be quite useless, it has to be a BOOPSI image class which can be used as replacement for something like
cutimage BitMapObject,
              
BITMAP_Screenscreen,
              
BITMAP_MaskingTRUE,
              
BITMAP_TransparentTRUE,
              
BITMAP_SourceFile"TBImages:cut",
              
BITMAP_SelectSourceFile"TBImages:cut_s",
              
BITMAP_DisabledSourceFile"TBImages:cut_g",
           
BitMapEnd;

Go to top


Re: OWB 2.11 !!
Just can't stay away
Just can't stay away


@Crumb

Quote:
-OS4.0 compatibility: for CSPPC OS4 owners
OWB 2.9+ doesn't need AmigaOS 4.1, 4.0 is enough, but it needs a current version of Cairo. The one from 2005 on os4depot.net is too old and unless someone else builds a current version for AmigaOS 4.0 the only one usable for OWB is the one included in AmigaOS 4.1, I don't have the time to port libraries OWB needs myself.

Go to top


Re: OWB 2.11 !!
Just can't stay away
Just can't stay away


@JCC

Quote:
I would *REALLY* like to be able to log into my Linksys router. I get "401 Unauthorized" instead of a login request window.
I've checked what's required for that, but it seems it would need additional code in at least 4 different parts of OWB to support it

An easy way may be adding it to libcurl instead, but I don't know if it caches usernames and passwords, it could be that you'd get the requester for each request, i.e. if there are 20 images on the page 21 requesters and you'd have to enter the username and password 21 times which would be unusable as well and much worse than having to enter the full URL with username and password, something like http://username:password@192.168.1.1/ , which works already.

Go to top


Re: OWB 2.11 !!
Just can't stay away
Just can't stay away


@sofistisoftware

Quote:
the % of cpu usage with 2.10 version is too high also when you leave it in st.by, example with amigans home page the cpu is busy about 50-85%,
FireFox needs even more CPU time on amigans.net, partially because of X11. It's because of the "4.1"s at the top.

Quote:
owb 1.25 use cpu on the same page about 10-30% and the scroll is a lot better in this old version
Did you have the "LOWMEM" tooltype enabled in 1.25 when comparing them? If not they do something completely different:
OWB Blastoise renders the complete page into an image, which, once that's completed, of course makes everything much faster, especially scrolling since it only has to blit parts of the pre-rendered page image on the screen, but that needs several 100 MB RAM for large pages.
OWB Doduo, like all other browsers incl. the AmigaOS 4.x port of OWB Blastoise with "LOWMEM" tooltype enabled, only renders the currently visible parts of the page and when scrolling it has to render the new parts (only in the AmigaOS 4.x port, on Linux it rerenders the complete visible part even when scrolling only a single line).

Go to top



TopTop
« 1 ... 55 56 57 (58) 59 60 61 ... 85 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project