They correspond to the '<' and '>' keys. AS they are menu short cuts they are not customisable for the moment. No it doesn't this is by design.
Oh, then pgup/pgdown its the same as "space" for go through files.
Quote:
These operate on the file list in MultiViewer
But if i disable directory scaning, disable file-lister, and then dbl-click on test file, probabaly then, pgup/pgdown may work for navigate over document ? (as there will be no other files to navigate over them)
The email issue is at your end as far as I can tell, perhaps you can email your tech support and ask why emails from the site get rejected?
I called them. They said that NO email is ever rejected. EVERY email that reaches the server will be delivered. Sometimes cropped (if they found a virus), but never completely ignored.
The error is on the end of amigadeveloper.com.
Because i DID get ONE email from Mantis. That was on the 10th of March 2018, since then something was changed server-side which now prevents the email ever going out from the server.
Who knows? Maybe the server has a blacklist with my email/isp on?
Maybe the server has a blacklist with my email/isp on?
Unlikely, blacklists are usually to filter incoming mail not outgoing. I have no access to any mailer logs, or similar, so much as I'd like to, can't help further, sorry for your frustration in this regard.
Don't forget that those keys do not necessarily exist on non-english/US keyboards. E.g. on mine I have one key (to the left of the Z key) with both those symbols on, one requiring Shift.
The keys on which you have them are for me - like it seems also for kas1e - the , and . keys.
@broadblues Is multiedit have some tooltype mean "Activate main editor area by default" so i not need to hover mouse over it to make it active ? What i mean is that now, when i in shell type let's say "multiedit somefile.txt", then if mouse is not under active typing area, then i can't type anything, as it inactive. I had to move mouse over it, which is not so nice as i don't need mouse there, i need start typing right away from keyboard.
That all of course with disabled file-lister and with disabled scanning of directories.
Maybe there is some way to got this by default without changes from your side ? Like maybe running by default some arexx script which will make that area active for me ?
All tests done on beta texteditor.gadget 53.26, multiedit 1.12.
Also seems found a bug, when i choice after running "scripts/bigger_font" : nothing happens. Then if i choice "Smaller font", then font start to be smaller, that fine, but in shell i have :
32 *-* RELOAD; +++ Command returned 20
Then, if i choice again "scripts/bigger_font", its instead start to be smaller again, not bigger.
I don't know if this is a bug per se, but it's awefull nonetheless imo.
With the enhancer package came some stuff for the SDK, including an updated libz.a file which sets the minimum library to z.library 53.6 or higher (which is not available to non-enhancer buyers).
Lately i was alerted that one of my ports stopped working for a non-enhancer amigaos4 user with the error message: Quote:
assertion "LIB_IS_AT_LEAST(ZBase, 53, 6)" failed: file "static/autoinit_z_base.c", line 33
I checked the other port and it brought up the same message when using z.library 53.5.
Why is it mandatory to set the libz version to a number higher than the official one available? That locks out every user who doesn't want to pay for the enhancer stuff.
I don't think i will spend any more time compiling yet another build just to support a vanilla amigaos4.
Is it mandatory to set the zlib version to 53.6? Can't it stay at 53.5 until the fragmented enhancer stuff becomes finally the "official" amigaos4?
Any ideas how i can rectify that without deinstalling either enhancer or parts of it or providing yet another slightly differing build?
I'd consider keeping a boot partition clean of that third-party Enhancer stuff as well as a clean instance of the SDK, activated from that clean boot. Then use that for your development.
You can set up another config/boot partition for using Enhancer and even another SDK instance which you allow Enhancer to add to, for developing stuff which is only guaranteed to work under the Enhancer.
Why is it mandatory to set the libz version to a number higher than the official one available?
It's not mandatory - unless libz.a uses some functionality only available in the new version of z.library. I think Fredrik Wikstrom is the author, so you had better ask him. Perhaps there is a good reason behind his decision.
Quote:
That locks out every user who doesn't want to pay for the enhancer stuff.
I can assure you that the Enhancer project does not apply a policy to deliberately lock out users who don't own the Enhancer kit. However, certain components may rely on other Enhancer components, either because they provide some necessary functionality, or because A-EON wants to be in full control of its dependencies. Makes sense to me.
It is because newer z.library versions have some new functions that were not in 53.5 and older versions (53.6 added Uncompress2(), 53.8 added InflateReset2() and 53.9 added InflateValidate()).
This one will only require z.library 53.5 at start, but if a program tries to use one of the functions only available in one of the newer library versions they will fail with the error code Z_VERSION_ERROR unless a new enough version is installed.
I don't know if this thing has already been pointed out but I found a conflict when using x-dock together with Sgrab. Indeed both programs use the combination "Amiga" + "H" to hide/unhide themselves so when I press that combination of keys they both disappear.. Maybe, is it possible to edit the key combination on X-Dock ? (I don't know if Sgrab is still developed and the coder is still around..)
The problem is not that they use the same shortcut (they should do that according to the style guide), but that only the program with an active window should react to it.
One of the programs must have a bug which lets it react even though it is inactive.
only the program with an active window should react to it.
I think you're mistaken on that, Nils. If a commodity has a defined hotkey for showing/hiding its GUI, the actual window state is not relevant. If it were, how could the commodity possibly react to the hotkey in hidden state, i.e. when its window is not active?