Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
123 user(s) are online (84 user(s) are browsing Forums)

Members: 0
Guests: 123

more...

Headlines

Forum Index


Board index » All Posts (xenic)




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


@Menthos
Quote:
Menthos wrote:
About downloads: would it be possible to just add a configurable context menu item that can call a command with the url or is that a too ugly hack to implement too?

I've already implemented an ugly D/L hack on my system. I have the "External Bookmark" menu set to open "HTTPResume" with a script set in the OWB TOOLTYPES. I select "Copy Link Location" in the context menu, open HTTPResume by clicking the "External Bookmark", click the gadget next to the URL string at the top of the HTTPResume window to paste in the URL and download the file.

In the OWB icon I have the TOOLTYPE:
BOOKMARKCOMMAND=owb_dl %s %s

owb_dl is a script that looks like this:

; AmigaDOS Script for D/L files with HTTPResume

.key owb_port,owb_screen,xxxx/F
.def owb_port "none"
.def owb_screen "WorkBench"

.bra {
.ket }

HTTPResume GUI STARTDIR="RAD:" NOCACHE PUBSCREEN={owb_screen}

It works well for normal links. JS links are a problem.

Go to top


Re: GCC, Switch( condition ) & Case
Just can't stay away
Just can't stay away


@freddix
I don't know about C++ but in C you will always end up with your DMode variable equal to the default case if you don't but "break" statements after each case like this:
switch( Depth ){
case 32:
DMode = GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH;
break;
case 24:
DMode = GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH;
break;
case 16:
DMode = GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH;
break;
case 8:
DMode = GLUT_DOUBLE | GL_COLOR_INDEX;
break;
case default:
DMode = GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH
}

Go to top


Re: My SAM experience : just 3 days now.
Just can't stay away
Just can't stay away


@Mrodfr
Quote:

DVI2SVGA give bad result on a CRT monitor. grey vertical line at the left of the screen or right of window opened.

Others have reported problems with monitor image quality when using the DVI2VGA adapter with SAM boards. Check out some of the other recent SAM topics here at Amigans.net.

Your problem sounds more like an adjustment/sync issue. I have never been able to switch a monitor from a classic Amiga to a PC (or my ?A1) with out making adjustments. If your monitor has settings on the front or on-screen settings, you may need to force it to re-synchronize to the output signal from the SAM. Some monitors will not automatically re-sync if the incoming video signal is close to one that it synchronized to previously.

Check the monitor settings in the DEVS:monitors driver for your system. Be sure those setting match your monitor specs.

As a last resort you may need to create a custom monitor mode with Picasso96Mode prefs. I haven't heard of many people needing to resort to that though.

It may require a little work on your part to get it working but may prove worthwhile in the end. Without knowing what settings are available on your monitor, nobody can probably tell you exactly what to do. I can tell you that the initial image quality on my ?A1 was crap, Text varied from clear to blurry accross the screen. I spent several hours fine tuning the display with the on-screen monitor settings and ended up with pretty good results.

Go to top


Re: My SAM experience : just 3 days now.
Just can't stay away
Just can't stay away


@Gebrochen
Quote:

CRT, hahahahaha, Are you NUTZ. Have you considered seeking therapy.

MAN, even retro geeks are using LCD's on their A1200 or 4000miggys with vga connection.

Look, CRT, AFAIK, No freakin way man, this is modern hardware with like ancient technology ou want to place onto it. Put simply, most of it wont work, because of ur Niche market. HENCE, get more modern stuff, so that things DO work. Like me, I straight away got a 4 hub pot, already had sb keyboard flexible, and my system came with a logitech mouse, but I am still using an older usb mouse. Infact, I got so many USB mice here, they all seem to work.


Plenty of graphics & video professionals use CRT monitors because it's the only way to get accurate display of all screen resolutions. When you use anything other than the native resolution on an LCD monitor, you are getting a calculated approximation of the actual screen image. If you place a good multisync CRT beside a high resolution LCD monitor and display the same 640x480 or 800x600 resolution screen, you will be laughing at the crappy looking LCD screen. A CRT monitor is a good choice if you want to use the same monitor for a classic Amiga and a SAM.

Go to top


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


@joerg
Quote:

joerg wrote:
Yes, OWB copies them as 32 bit ARGB images to the clipboard. I didn't expect there is that much software which doesn't support 32 bit images, I'll change it to 24 bit RGB without alpha in the next version.


Given the fact that some of the best Amiga graphics programs are a little out-dated, that's probably a good idea. It would't hurt to leave the current code and create a prefs option (TOOLTYPE) to save 32bit ARGB images for those who want the image's alpha channel preserved. There are some Amiga programs that can use the alpha channel. It won't be much of an issue once OWB can save the original image file.

Go to top


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


@gerograph
Quote:
What happens to the Images (Imageformat) when they get up- or downloaded?

Nothing. They are probably 32bit images. Multiview just saves them as 32 bit IFF ILBM images. Older programs & some current ones know about 24 bit only and load the 32 bit images as 24 bit images. I D/L an image from this site, saved it from Multiview (has stripes when viewed in an old program), loaded the image into ImageFX-lite, saved the image as Targa (not Targa-alpha), loaded the Targa image into Multiview and saved. The resulting image is then 24 bit ILBM and shows up in older programs without stripes. There is probably some utility on Aminet that will convert 32 bit ILBM images directly to 24 bit (SView5?) instead of using the convoluted procedure I just described.

Go to top


Re: Issues / Observatons with the new SDK 53.13
Just can't stay away
Just can't stay away


@BillE
Quote:

BillE wrote:
> That's the problem that has me stumped. Newlib does
> define errno in sys/errno.h included by errno.h

I noticed that too but for some reason the compiler or linker does not seem to find it ?

I fixed my timeval & errno problems with 2 changes. Because of some problems created by differences between the old clib2 network related includes and the SDK network includes, I had added "-ISDK:include/netinclude" to my makefiles for the old SDK. Removing that directive fixed most of my problems. I removed the "include errno.h" and replaced it with "extern int errno". My programs now compile and link, although I'm not sure if errno works. I think the SDK network includes might need some updating to avoid include problems but all seems well for me now.

Go to top


Re: Issues / Observatons with the new SDK 53.13
Just can't stay away
Just can't stay away


@Rigo
Quote:

It's not treated differently, it's depreciated. The TimeRequest structure has superceeded it, and the fields have changed names too. Check devices/timer.h for further info.

Apparently, somebody forgot to tell Roadshow's bsdsocket.library about the deprecation because functions like WaitSelect() still use struct timeval. If the bsdsocket autodocs and includes aren't updated then you have no choice but to use the __USE_OLD_TIMEVAL__ definition.

Go to top


Re: Issues / Observatons with the new SDK 53.13
Just can't stay away
Just can't stay away


@BillE
Quote:
"undefined reference to `errno'"
which when using clib2 just including errno.h works but not with newlib.

That's the problem that has me stumped. Newlib does define errno in sys/errno.h included by errno.h but the linker doesn't accept or recognize it because I get the same error as you. It's easy to solve missing value definitions, even it you have to define them in your program, but missing functions are a different story. Apparently newlib still isn't up to snuff yet so I guess I'll have to stick with clib2 also. I wonder how you could port a *nix program using newlib if errno doesn't exist?

Go to top


Re: Issues / Observatons with the new SDK 53.13
Just can't stay away
Just can't stay away


@ktadd
I ran into the same type of problem with MAXPATHLEN. It's defined in clib2 but not in newlib. There's not much you can do but define it in your sources or some include file that you use with all your programs.
As far as your error goes, could the function have a return value that you're not using?

Go to top


Re: AmiCygnix doesn't seem to do anything
Just can't stay away
Just can't stay away


@RacerX
I just installed it recently myself and really can't tell you much. I have noticed that the double-click timing is a lot faster than what I have set for Amiga Input. I have to double-click so fast that it sometimes takes several tries.
Did you install the Base and Tools archives?

Go to top


Re: Installation problems & bug on OS 4.1
Just can't stay away
Just can't stay away


@Cool_amigaN

Quote:

I thought that it was possible some of the feautures my keyboard has (e.g zooming in/out) to be disabled due the absense of drivers but I wasn't prepared to see that it was not working at all! If that's the case with usb devices on AOS 4.1 then how am I supposed to know if a usb device will work or not? I am thinking of Microsoft Sidewinder X6 or the new Illuminated keyboard by Logitech (both quite expensive). What am I supposed to tell to the store where I will buy them: Wait a sec, I will give them a try in OS 4.1 and if they do not work I will return them? :P

No. You tell them it didn't work and would like a refund. In the USA they are more or less forced to refund if you use a credit card. Surely you realize by now that most computer accessories are designed to work on a Windows PC and not to the specifications for a particular protocol (USB, Internet etc.).

Go to top


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


@joerg
Quote:
I wont implement a disk cache in OWB this year[

That's fine. I have no complaint about the speed and was only pointing out that some people may notice a speed difference if they are on dialup but possibly not if on a high-speed connection.

Go to top


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


@retro
Quote:

faster ????

hehehe it runs faster then firefox here

Your speed may depend on the connection type. With my dialup connection IBrowse loads the Amigans news page in 19 seconds while OWB takes over a minute. I think that disk based caches (like IBrowse & AWeb use) make a big difference with some site when you're using dialup. It may not make much difference with a high-speed connection and some sites change so frequently that caching is not very useful.

Go to top


Re: Opening OWB from IBrowse
Just can't stay away
Just can't stay away


@ZeroG
I added it because OWB froze my system while I was editing a post here at the Amigans site. I had to reset the computer twice to get going again. I checked with Ranger and it seems to have a stack of 266000+ if the stack isn't increased in the shell. The extra stack won't hurt and my freeze may have just been a coincidence.

Go to top


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


@joerg
I just provided a script to start OWB from IBrowse in another thread titled: "Opening OWB from IBrowse". Please check it out and add any corrections that might be necessary. Does OWB actually need the 500000+ stack shown in the OWB icon? I used a similar stack size in the script I posted in the above mentioned thread and just want to be sure that it's correct.

I noticed that when run from a shell, I don't get an argument template when I enter "OWB ?". Are there multiple arguments (other than the URL which seems to work) and if so what is the TEMPLATE for them?

Go to top


Re: Opening OWB from IBrowse
Just can't stay away
Just can't stay away


@ZeroG,Elwood

I've encountered this problem before and it apparently occurs because IBrowse is already redirecting the output to a console (>CON:0/0/640/200/IBrowse...) when it launches a command. I don't think you want to redirect error output because you won't find out when something goes wrong with command startup. However, you can start OWB with a short script and redirect standard output to NIL. Here is the script I use:

; AmigaDOS Script for starting OWB from IBrowse
.key owb_start,xxxx/F
.def owb_start " "
.def xxxx "extra_args"

.bra {
.ket }

stack 500000
path/OWB >NIL: {owb_start}
; End of script

Replace "path" with the actual path to OWB on your system. I named the script "Start_OWB" but you can use any name you like. Be sure to set the "S" protection bit so that AmigaDOS recognizes it as an AmigaDOS script. Copy the script to your IBrowse directory. Enter the script name in the Action:Command string in the Button Configuration section and %u for the argument. When you press the button in the IBrowse toolbar, OWB should open with the same page displayed by IBrowse.

Please note that I've edited this post and added a stack command to the script. The OWB icon sets the stack to a similar value and it might be unstable without a large stack size. If OWB is still unstable you could try increasing the IBrowse Preferences/General/External Applications Default stack size to a higher value. I wouldn't do that unless necessary because it will waste memory providing a much larger stack than most Amiga programs need or will use.


Edited by xenic on 2009/1/18 18:05:09
Go to top


Re: Problem with SDK and AmiCygnix
Just can't stay away
Just can't stay away


@cygnusEd
Quote:

Ah - so you mean, that it would be better for you NOT to set ENVARC:PATH?

Yes. It would be better if it was in ENVARC:AmiCygnix so that there are no conflicts with other *nix based programs.
Quote:

The problem appeared here caused by "idesk", the desktop manager. Sometimes idesk seems not to be killed, when AmiCygnix is stopped. If you relaunch AmiCygnix, idesk opens the timer.device all the time. I suggest to stop idesk by sending a break signal with "Scout" (or similar program) before starting AmiCygnix again.
But most times idesk works o.k.

I just tried starting AmiCygnix after a reboot and did not see the continuous opening of the timer.device. It would be nice if you could fix that eventually because it creates and unnecessary burden on AmigaDOS that could slow down the entire system. Snoopy doesn't show if the device is being closed each time it is opened but if not I would think that the timer.device open count would overflow eventually. I just checked the open count with Ranger and that doesn't appear to be the case; the open count is stable.

Oops. I rebooted before going online and started AmiCygnix after beginning this message. It is continuously opening timer.device again. This behavior seems to be somewhat inconsistant since it didn't do it when I opened AmiCygnix after a reboot but before starting other programs. Maybe it has something to do with being online (dialup connection). Maybe I messed up some AmiCygnix network settings if there are any. I didn't pay much attention to that.

Go to top


Re: Problem with SDK and AmiCygnix
Just can't stay away
Just can't stay away


@cygnusEd

Quote:

I don't understand, why it didn't work for you to set ENVARC:PATH to your needs. The AmiCygnix startup will not touch it. The only disadvantage is, that all paths in the scripts called by abc-shell must be absolute. This should be the case in the scripts included in my packages.


It works but ENVARC:PATH creates conflicts with other programs. Some commands in the minimal GeekGadgets installation I have for compiling 68k programs use the ENVARC:PATH variable if it's set. My older version of the CVS command looks for the PATH variable. I think that the OS4 SDK gdb command gets search directories from the PATH variable. I think that the abc-shell author moved the abc-shell variables to the SDK:Data/abc-variables file to avoid such conflicts. Since abc-shell is at SourceForge it shouldn't be too hard to compile a custom version for AmiCygnix that doesn't use ENVARC:PATH.

Quote:

The problem with shexec and SHEXEC_SHELL is a bug. I will fix this. Thanks!

Glad to help and thanks for programming AmiCygnix.
Quote:

It is no accident, that AmiCygnix looks like GeekGadgets. Both are unix like environments and the X11 code is based on a geekgadgets port. So don't be surprized .


When I get the time I may try moving my 68k GG compiler to the AmiCygnix directory tree to see if I can use it from there instead of the GG environment.
Quote:

The timer.device problem does not appear on my system. Which OS4 version do you use?


Maybe it was one of the applications and not AmiCygnix itself. I'll take another look and see if I can provide you with more details.

Go to top


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


@joerg

OWB is certainly progressing. I only have a minor problem to report. When I open OWB on an open public screen (my Internet screen), OWB takes the focus (becomes the active window) but doesn't bring the screen to the front. It would make more sense for it to pop the screen to the front if it's the active window. Other than that OWB is great! Keep up the good work.

Go to top



TopTop
« 1 ... 61 62 63 (64) 65 66 67 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project