Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (msteed)

Bottom

« 1 (2) 3 4 5 ... 8 »

msteed

Re: wb2filer v0.5

Posted on: 12/4 7:36 #21

Just popping in

@kas1e

Quote:

Anyone have an ideas how to made it in clean and better way ?

Seems like a good idea to get rid of the WhichWorkbenchObject() stuff and just use the list of selected icons to find out which drawer to point Filer at. That should cure the problem where using 'Open' from the Workbench menu opens a Workbench window rather than a Filer.

As far as handling multiple icons, here's one possible way of doing it, presented in pseudocode, so I don't have to worry about getting the syntax exactly right.

First, create a global variable called 'which_icon', which defaults to zero (computer numbering, where 0 is the first icon, 1 the second, etc.)

Now replace the WhichWorkbenchObject() code with something along the lines of:


Use WorkbenchControl() and WBCTRLA_GetSelectedIconList to get the list of selected icons. Get the first icon from the list (GetHead()).



Call GetSucc() 'which_icon' times, to get the which_icon'th entry in the list. Check to see if there's another list entry beyond this one (GetSucc() doesn't return NULL). If so, increment which_icon for next time. If not, reset which_icon to zero.



Get the drawer's name from the list node and either pass it on to Original_OpenWindowTagList() or open a Filer and pass the drawer name to it. You don't have access to the icon type, so you'll need to look for a ':' at the end of the name to tell if it's a disk icon or not.



Free the selected icon list with WorkbenchControl() and WBCTRLA_FreeSelectedIconList.

The idea is that if more than one icon is selected, then each time OpenWindowTagList() is called one of the selected icons will have its window opened. The which_icon variable keeps track of the next entry in the list, the one that will have its window opened the next time OpenWindowTagList() is called. Once the last entry has had its window opened the variable resets to the first entry again for next time.

To keep the pseudocode easier to follow I left out error handling, such as dealing with cases where there are no selected icons (the list is empty), or if the list unexpectedly ends (the which_icon'th entry doesn't exist).

Topic | Forum

msteed

Re: wb2filer v0.3

Posted on: 12/1 7:50 #22

Just popping in

@kas1e
@balaton

Quote:

...minimise the possibiliy something else also calls DisplayBeep before your command and clears the flag. This may also happen sometimes anyway I think but that was already said by the original poster of this idea.

I was actually thinking that the DisplayBeep() patch would check to see if it was being called by Workbench by calling FindTask(NULL) and checking the task name, just like the OpenWindowTagList() patch does. Only if the disable_flash_beep flag is set AND the caller is Workbench does the call get blocked and the flag get cleared.

That way, the only way it can go wrong is if Workbench calls OpenWindowTagList() a second time before it calls DisplayBeep() the first time. Depending on how Workbench is structured internally, that ranges from highly unlikely to impossible.

@kas1e

While playing with the program I noticed some issues that may be bugs or may be features

.

1. If you click on an icon and then select 'Open' from the Workbench menu you get a Workbench window, not a Filer.

2. I figured a good torture test of the DisplayBeep() patch would be to shift-click a number of icons, then shift-double-click the last one, to open all the icons at the same time. DisplayBeep() worked fine, but all of the Filers that opened were for the last icon, the one I double-clicked.

Topic | Forum

msteed

Re: wb2filer v0.3

Posted on: 11/30 2:06 #23

Just popping in

@kas1e

Quote:

The thing which i dislike and also want to deal with is this "blink" of the title bar when you dbl-click on icon...

As long as you're hacking anyway, you could always patch DisplayBeep() to ignore calls from the Workbench task. Of course, then you stop Workbench from flashing the screen for any reason.

A more elegant fix would be to have a global flag that is shared by both the OpenWindowTagList() patch and the DisplayBeep() patch. If the flag is clear, as it normally would be, the DisplayBeep() patch allows Workbench to flash the screen. When the OpenWindowTagList() patch opens Filer and passes NULL back to Workbench, it also sets the flag. When the DisplayBeep() patch sees the flag is set it blocks Workbench from flashing the screen that one time, and then clears the flag. That way, only the next Workbench call to DisplayBeep() after a new Filer window is opened is blocked. All other DisplayBeep() calls from Workbench are allowed, as well as calls from any other program.

Multi-tasking might mess with this scheme, but that shouldn't be a problem with Workbench, as it typically only does something in response to user actions, so it's effectively single-threaded. If it gets it wrong on rare occasion, hey, it's only a hack!

Topic | Forum

msteed

Re: DrawerGenie for AOS4?

Posted on: 2023/11/16 7:35 #24

Just popping in

@kas1e

Quote:

Do we have any system-utility which printf for us a flags/tags/etc of a given window ? (so we can compare to know what flags have said RamDisk window when opened).

Scout can do that.

Topic | Forum

msteed

Re: DrawerGenie for AOS4?

Posted on: 2023/11/16 7:29 #25

Just popping in

Just a thought: Since the patch is presumably called in the context of whatever task/process is opening the window, could you just call FindTask(NULL) and then check the task's name to see if it's the Workbench?

Of course, Workbench opens other kinds of windows too, such as the About window and various requesters. But those don't seem to have WFLG_WBENCHWINDOW set.

Quote:

I found in my tests that even Notepad had the WFLG_WBENCHWINDOW set.

So does UnArc. And MultiView. And the AmiDock window. And some others I tried. Clearly this flag alone isn't sufficient for determining if a window belongs to the Workbench or not. But maybe the flag and also checking for the Workbench task would work.

(On the other hand, it looks like the Workbench backdrop window also has WFLG_WBENCHWINDOW set, and it presumably is opened by Workbench.)

Quote:

We have many features in context menus already so is this WB toolbar really that much necessary ?

I had that thought too, but if others feel differently, I support their enthusiasm for figuring out another way of doing things. And if a technique for adding a file manager toolbar to a Workbench window can be worked out, the same technique might be used to add other functionality as well.

Topic | Forum

msteed

Re: gcc 9 and 10

Posted on: 2023/11/10 7:34 #26

Just popping in

@joerg

Quote:

On G2/G3/G4 CPUs the MMU memory attributes, incl. the executable bit, aren't used by the kernel IExec->IsNative() function, and similar code in the m68k emulator, at all. It just checked if the address of the code is in the 256 MB executable segment address space, IIRC 0x70000000-0x7FFFFFFF

As I noted a while back while investigating elf file loading on my X1000, the 'executable' attribute does not appear on memory where the .text segments are loaded. However, the addresses where the .text segments are loaded seem to all be in the 0x7xxxxxxx range. So it would appear that the X1000 kernel handles memory the same as the G2/G3/G4 kernels do.

Topic | Forum

msteed

Re: SAM460LE case panel connectors

Posted on: 2023/11/8 2:56 #27

Just popping in

@Hitman

Connecting the LEDs backwards shouldn't hurt anything; they just won't turn on. If that happens just reverse the connection. You can try the power LED first, since it's on all the time. The HD LED is almost certainly the same polarity.

Topic | Forum

msteed

Re: Internet speed test that works in Odyssey?

Posted on: 2023/11/6 6:37 #28

Just popping in

I've recently stumbled across another Internet speed test site that works with Odyssey: speedof.me

There is one issue: The time it takes to draw the progress display substantially slows the test, even on an X1000, resulting in an inaccurate result. To get around this I open a second tab in Odyssey, and switch to it as soon as I click the 'Start Test' button, thereby hiding the speed test tab. By watching the network activity indicators in the lower right corner of the Odyssey window I can tell when the test is complete, and I can safely switch back to the speed test tab to see the test results.

There's also currently a version of the test without all the graphics at: speedof.me/api/doc/sample1.html
It doesn't require any workarounds, but is really intended as a demo of their API and so may not continue to be available.

Compared to testmy.net this site tends to show somewhat faster speeds, at least for me. Based on other testing (downloading large files from web sites) I believe the testmy.net results are more accurate. YMMV. The testmy.net test is also more configurable, allowing you to choose the test upload/download sizes and select which server to use. Still, it's nice to see another site that actually works with Odyssey.

Topic | Forum

msteed

Re: Advice for X1000 Video Card

Posted on: 2023/9/27 4:12 #29

Just popping in

@mufa

Does the R7 240 warm boot? I have the seemingly fairly similar R7 250 in my X1000, and it definitely does not warm boot (using the HD v.3.7 driver).

Topic | Forum

msteed

Re: can anybody explain about current situation with BREL Relocations ?

Posted on: 2023/8/23 7:51 #30

Just popping in

I've played around some more with linking with and without -N, and what effect that has on the resulting executable.

elf.library allocates tracked memory when loading a program, so the TrackedAddr tab in Ranger conveniently shows all the loaded sections and the addresses they live at (the sizes of all the tracked memory allocations exactly match the section sizes that readelf reports).

Ranger doesn't report the memory attributes of those allocations, so I wrote a quick'n'dirty tool to call IMMU->GetMemoryAttrs() for any address I give it. With this I was able to confirm that the only difference between code linked with -N and code linked without it is that the .text section is writeable with -N, and is read-only with the standard ldscript. .rodata and .__newlib_version are read-only for both both ldscript versions, and all the other sections are writeable for both versions.

Curiously, the .text sections are not marked as executable, at least not as reported by IMMU->GetMemoryAttrs(). The address of the loaded .text sections is notably different than all the other sections, so perhaps some other mechanism is used to set aside a block of memory as executable. (Maybe the segment registers joerg mentioned? This is an X1000...)

Leaving the code writeable is more of a risk, especially for a program like PassPocket that is trying to prevent malicious code from potentially messing with it. So I guess it's time to change my linking habits.

Topic | Forum

msteed

Re: can anybody explain about current situation with BREL Relocations ?

Posted on: 2023/8/17 8:19 #31

Just popping in

I was remembering the alignment incorrectly; it is actually 4K. When you're looking at a little Hello World program that's a few hundred bytes, a 4K aligment gap seems enormous.

As a test, I rebuilt my PassPocket program -- which was linked with -N -- using the normal ldscript. I got lucky with the alignment gap there; the program grew by only about 800 bytes, or less than 1%. Worst case it might have grown by nearly 4K, though that's still less than 5%.

To help understand the difference, I looked at the executable for both versions with a hex viewer. Both versions have an alignment gap between the .text section and the .rodata section, so .text can live in its own executable memory page. The page certainly could be made read-only as well, though the -N version's ELF file specifies it as writeable (is there a tool of some sort that would display this information?).

The standard version also has an alignment gap between the .rodata section and the .data section (and all the other writeable sections that follow), while the -N version does not. I suppose that makes the .rodata section writeable in the -N version, since it would live in the same memory page as the other writeable sections.

I'm not sure how big an issue that is. I guess if a bug causes the program to try to write to the .rodata section it would trigger a DSI that would point out the problem and allow it to be fixed, while the -N version would not get this protection. And there would be some degree of protection against some other program running wild and scribbling over the .rodata (or over the .text section, if that's write protected), though that's not something that's very likely to happen.

Topic | Forum

msteed

Re: can anybody explain about current situation with BREL Relocations ?

Posted on: 2023/8/15 7:59 #32

Just popping in

I've been following this thread with interest, as I've always used -N when linking my programs. IIRC, the alignment with the standard ldscript is 64K, which ends up leaving a lot of unused empty space in the executable on disk, and I suppose in memory as well. For modest-sized programs the waste is significant, and using -N substantially reduces it.

That's the benefit to using -N. Is there a downside?

Topic | Forum

msteed

Re: Is this a glitch or is it normal?

Posted on: 2023/7/8 21:12 #33

Just popping in

@broadblues

Quote:

But if I read the thread correctly you do not currently see the issue?

I can't confirm seeing the issue since I installed my new graphics card a few months ago. But neither can I confirm that I haven't seen it. I just got used to seeing the glitch now and then and stopped paying much attention to it. I upgraded the RadeonHD driver just before installing the new card, so I can't confirm seeing the issue with the newer driver, either.

Quote:

You saw it with your old card?

Definitely.

Quote:

What gfx lib would you have had had installed when using that card?

The same as now. I only upgraded the card recently, so I ran for a long time with that version of graphics.library and the old card.

Topic | Forum

msteed

Re: WebKit based browser initiative

Posted on: 2023/7/8 4:36 #34

Just popping in

@walkero

Thanks for the status update- it's good to know that progress is being made. It seems like every day Odyssey loses the ability to access another web site that used to work, so work towards an eventual replacement is very welcome.

Quote:

The work we do for webkit requires changes in adtools and gcc itself. This means that we do not actually work only on the webkit but a lot more stuff around our dev environment.

Something to look forward to in the next SDK!

Quote:

A couple of week ago we finished the majority porting of the needed third-party libraries like the harfbuzz and many others. They are all compiled with afxgroup's clib2 and are available at his ubuntu packaging server.

Hopefully these ports will also show up some place like OS4Depot, where they're accessible to native developers.

Topic | Forum

msteed

Re: Is this a glitch or is it normal?

Posted on: 2023/7/8 4:04 #35

Just popping in

@broadblues

I've got graphics.library 54.248, as supplied with Update 2. As far as I know, that's the latest public release.

Topic | Forum

msteed

Re: Is this a glitch or is it normal?

Posted on: 2023/7/2 3:58 #36

Just popping in

@nbache

Quote:

You might consider making backups of the relevant .prefs files in ENVARC:Sys/ - or if you're lazy, simply backup the whole directory.

I make regular backups of the entire system partition (and all the others), so I can restore the preferences if I need to. But you're right, making a temporary copy of just that directory would make restoring the preferences easier after playing around with them.

Quote:

BTW, what about the font you're using for the title bar, has that been changed? Just an idea.

I'm using DejaVu Sans 15 as my screen font, which is the one that's used for Workbench window titles. I think that's the default font, though maybe not in exactly that size.

I've also got a stock FE (Update 2) partition I can boot from, with no changes at all except for the graphics driver. But the problem with trying to use that, or experimenting with changes to the preferences, is that the glitch is so random and infrequent that it's not practical to try changing things to see if it makes a difference- even if I didn't see the glitch for days or even weeks I couldn't be sure that it was because of the change I made, or if it just hadn't happened to show up. Just as I'm not sure now whether changing the graphics card and updating the driver made a difference.

Topic | Forum

msteed

Re: Is this a glitch or is it normal?

Posted on: 2023/7/1 7:07 #37

Just popping in

@Deniil

My old card was an HD6570, and I definitely saw the problem when I was using that card. I was using the old v. 1.7 Radeon HD driver at the time. I'm using an R7 250 and the v. 3.7 driver now; I'll keep an eye out to see whether the problem ever occurs with my current setup.

@tonyw

Quote:

I would first revert to the standard GUI theme

I started with the standard theme, but have made adjustments to the various settings to suit my taste. Looks like I'm using the "Subtle" bitmap set for the window borders; I think that was the default set, but I don't recall for certain now.

Having spent a lot of time getting the look I want, and getting Reaction and MUI synchronized so everything looks consistent, I'm not inclined to change any of the settings now.

Quote:

I would next check the versions of graphics.library and diskfont.library,

graphics is 54.248, and diskfont is 53.13. Should be standard FE Update 2 stuff. Though as I noted, I had the problem when running Update 1 as well.

Quote:

Does it only appear in the window title, or is it visible on other text in the window?

I've never seen it anywhere but in the window title. It would be a more serious problem if it showed up elsewhere.

Topic | Forum

msteed

Re: Is this a glitch or is it normal?

Posted on: 2023/6/30 7:51 #38

Just popping in

@rjd324

I've been seeing that for years on my X1000 (I thought I was the only one...), ever since I upgraded from 4.1.6 to FE Update 1. I was hoping Update 2 would fix it, but no luck.

As with you, it seems random and completely unpredictable. I've only seen it on Workbench windows, but it's inconsistent as to when it happens, and which window is affected (usually just one window, but not always). It seems more likely after I've been using the system for some time, but that's inconsistent, too.

Sometimes it takes the form of a solid line under the entire title, as in your screenshot. Other times it's only part of the title that's underlined. And sometimes it's more like an irregular dashed line that's different each time I open the window. I've even seen it change while the window is open.

It seems harmless, and doesn't appear to affect anything beyond the window titles. I've never even considered reporting it, since it's so random and irreproducible. I recently upgraded to a new graphics card and driver, but I've gotten so used to ignoring the glitch that I can't even say for sure if I've seen it since the upgrade.

Topic | Forum

msteed

Re: AmiUpdate and newlib.library....

Posted on: 2023/6/24 4:33 #39

Just popping in

@Cageman
@smarkusg

My SiteList file contains the following:


AmigaOSUpdateServer

MyHyperionUserName

MyHyperionPassword

Where, of course, you use your actual user name and password. There's a return at the end of each line.

This issue has come up before, see post #8 et seq in this thread. Creating a proper SiteList file seems to solve the problem.

Topic | Forum

msteed

Re: Which And Path Confusion

Posted on: 2023/6/14 2:58 #40

Just popping in

Speaking of confusion: Does anyone else get a blank page after clicking the 'Reply' button below post #4 in this topic? (If you do, the browser's 'Back' button will get you back to the topic page.)

I notice that post #4 has a matched '<' and '>' in it, just like the post I was trying to compose over in the "current situation with printing" topic that caused blank pages when previewed. Something weird seems to be going on with the forum software when those two characters are present in a post.

Topic | Forum

Top

« 1 (2) 3 4 5 ... 8 »