@thellier

Surprised? Why?

Text() is known to be very slow on PCI(e) machines without (active) DMA facilities. Maybe because of read-from-vram-cycles involved when "blitting" the text without a real blitter. The SAM machines have a slight advantage here with DMA (but it is still a speed penalty to use Text() on bitmaps located in vram).

@broadblues

I understand quite well. Voxel statet, which tools he used to format (and to show) the partitions. One of those tools is sfsformat. So, the essence of joerg´s answer is: "you didn´t use the right tools. All is working fine, under the hood. It´s all about outdated software using 32 bit integers".

At least sfsformat should print out correct values, if used on SFS2 partitions.

@joerg

Pls note, that the following is not meant as trolling.

What do you think: why people are telling you, that there is something working not correctly? Do you think they just "imagine" problems because they don´t have deep knowledge of the internal workings of your product?

I want to tell you, that you should take such reports more serious. The average user just sees what the SFS tools are telling him. If the output is plain wrong, it would be a better solution to repair or expand or fix those tools instead of telling stories about "hey, the tools are printing out plain BS, but in the background all things work ok, and it´s not my fault that things are like they are".

@Dandy

I don´t think that anybody here wants to hinder you trying to get the TP-Linux drivers working with TP-Amiga. I rather think that you won´t have any success with it.

It´s a pity that Irsee won´t do us the favour to update TP-Amiga to the level of TP-Linux. Maybe enough money would change this, so if you would be so kind to spend them several 100000 €...

LG G4 works more or less with PTP. Right after the download is finished, PTP comes up with an error and quits. But the download is done. So, works more or less ;)

@Severin

Ah, missed the "e", right... I´m getting old, I think

@mritter0

IIRC, you should use

LhA -x2 RAM:archive.lha Drawer1/Drawer2/TheFile RAM:

to get what you want.

@nubechecorre

Hehe, well, I´m using OS4.1 FE already SimpleMail has other quite serious problems (e.g. truncation of sent mails without apparent reason, automated email transfer not working etc., reported already), so I wanted to change back to YAM.

Wasn´t the best idea, I think...

I resurrect this rather old thread in order to (hopefully) get an answer, as I encountered the same problem...

YAM isn´t able to receive email via pop3.strato.de, it cancels the connection with a generic "error initializing TLSv1/SSLv3 session with server "pop3.strato.de" of...". It is using port 995, as described in strato´s server configuration help.

Interestingly, YAM is able to send email via smtp.strato.de using TLS/SSL at port 465.

Is there any way to make YAM receiving emails using the strato pop3 server?

@LiveForIt

Interesting code, thank you very much!

slightly OT:

If anybody with an AmigaOS Wiki account reads here: The measuretext.c example is unusable in it´s current form. Several typos and wrong Tag naming, not to mention "interesting" code practices ;)

I made up a version that is at least compiling with the latest public SDK. The code needs some overhaul to reflect latest recommendations regarding typing etc.

@BSzili

I do.

But who talked about "Microsoft" or "OpenDocument"? I didn´t talk about that at all. IMHO, it is quite unimportant if a e.g. word processor is "compatible" to any standard and/or open source solution. Nobody would use e.g. LibreOffice on a PPC equipped classic machine. Not to mention doing serious work with this combination. So this port would be about fame, but not usability.

If I should use it on a x86/x64 machine, I wouldn´t use any AmigaOS derivate, because the AmigaOS port would be outdated by nature and would be haunted by security problems.

@BSzili

Let´s see... native office suite or at least a working and usable word processor program? Never touched because "it´s much easier to port xy!" (e.g. LibreOffice).

Work on printer drivers? Never really touched because of the (how often? One dozen times? Two?) broken promise of CUPS being ported AND working soon... I think there are lots of other examples.

In the end many efforts and time resources are spent on ports, with questionable use and/or success. That doesn´t mean that there are no porting projects with use, in fact there are a few. But those are stuck quite often (Odyssey for example. Or VICE) and always outdated.

There are some native programs/games at least, but IMHO there would be possibly much more, if the main focus would be more on those than it actually is on questionable ports.

@trixie

Maybe that´s because there is not enough manpower to develop such software. And there´s not enough hardware power to actually use it, either.

I think the "porting business" is blocking (to a certain amount) native software development. People don´t get the point of the critics against "porting all and everything", because it looks like "easy doin´" for them. Those people can´t see that it is indeed NOT easy to port complex software packages.

@joeled

Maybe you should ask for native software works, too?

@Hans

I don´t know the implementation details of the SDL alpha blit function, but I would think that it blits rectangles.

AbbayeDesMortes uses the vertex mode of CompositeTags() (as I do in my several test programs *hint* ), that´s why I think that it isn´t very SDL-ish...

@K-L

This one doesn´t use SDL at all... it´s more after "CompositePOC" (Aminet). The concept used there is not very SDL-ish, and I think that compositing could be used in SDL in very few points (blitting incl. alpha channel, for example. But not with RLE surfaces etc.)

Asynchronous? Impossible due to the group/object layout mechanism used. How should the layout know how to layout if the window resizing isn´t done? AFAIK the layout domains are dependend on the window´s visible/inner size.

I didn´t use MUI that much, but I presume that it is using the way broadblues suggested within it´s application object/layout loop.

Layouting is deferred until the window resize operation is done (using some timeout).

@Hans

Thx for the hints

Well, if the source bitmaps are RLE, it´s quite a bit difficult to use graphics.library functions to blit them , but for some other things it might be an easier solution.

Thx!

@Hans

Thank you for the clarification. I asked because even oldschool stuff could be very slow using BltBitMapTags().

I hoped that at least 8 bit chunky gfx operations would be accelerated (well, using mask planes for blitting). So I think using WritePixelArray() (and some RLE code writing to CPU memory) would be the better idea...

@Hans

What about BltBitMapTags() with masking into a destination bitmap with same attributes? Accelerated?

I believe (I don´t know for sure yet) that KeyShow would do the trick, if it would consume the mouse click into its window.

MUI & ReAction interprete a mouse click outside the layout or gadget bounds as "deactivate that particular gadget and don´t accept an input". If there is no mouse click event, there is no deactivation.

I think that´s the reason why it does work for some programs (Shell, Calculator), but not for MUI/RA gadgets.