YAM DragNDrop when streaming radio via TuneNet

Hello:

Is it just me, or is it next to impossible to drag a message from the Inbox to another folder while playing Internet radio with TuneNet?? I have tried many setting changes to MUI prefs to no avail. All is fine if I stop the playback. So I wind up moving the Inbox message via the toolbar move button.

@amigadad

Happens in all MUI apps. Try drag&drop in mui prefs for example.

I don't think this can be helped unfortunately.

@orgin

I am not a programmer, but it would apear that DragNDrop is trying to hog the system and OS4.1.1 is not letting it. Just my opinion, not sure if it is correct or not.

@amigadad

This is a known issue. MUI locks the current screen hard during DnD operations. This behaviour is exactly the same since ages. The lock is necessary because the dragged object's image is drawn directly onto the screen and the lock guarantees that no other application can draw anything (and thus destroy MUI's dragged image). Unfortunately MUI's lock is not as uninterruptible as stunzi originally wanted it to be and other applications might break it. This leads to the aborted DnD operation as this is the only possibility to prevent deadlocks.

I am currently working an a solution for OS4, but this requires hi/true color screens and compositing enabled. With this solution there is no need for such a hard lock anymore.

@tboeckel

Thank you for the clarification!
For now I will avoid DnD while listening to internet radio.

@tboeckel

EDIT: okay I should have read better the thread I understand the reverse : DnD would interrupt music playing.

Anyway I never use DnD in NList object especially in YAM as you never know what you'll finally move (maybe it's just me but 1 time out of 2 I ends up selecting the following message while trying to drag a selection). So I found using the toolbar a more secure way

@amigadad

The same (interrupted DnD in YAM and other MUI apps) happens when OS4's Notification takes place. Whenever a Noti window comes up one cannot DnD in YAM as it will be interrupted.

So you don't even need to listen to music

@amigadad

I put in some code in earlier versions of TuneNet to try and get around a similar problem with the update of the slider gadget and D&D.

Potentially I could freeze all TuneNet gadget updates when it is not the active window, which would get round the problem, but then things like the timer would freeze also. This might look a little odd.

I'll take another look at this after I get the service release out (which is actually turning into a new version as I'm adding features). No promises on a work around though!

Cheers,
Bean.

@amigadad

Quote:

Try that when Tunenet is in SkinFX display mode.
Tell us what happens!

@lazi

Quote:

DragNDrop works fine when using SkinFx display, why the difference??

@bean

You could partly solve this issue by using separate tasks for playback and GUI. GUI is messaged from the playback task regarding progress of playback (timer) and other things necessary to know for the GUI task.

This way you could avoid the full stop on locking menu actions as well

hmpf, typo...

@whose

Hi,

TuneNet already uses multiple processes to do things. You can see this by using a tool like Ranger. The player is totally separate from any GUI update.

The issue is between Intuition (Reaction gadgets) and MUI.

Cheers,
Bean.

@bean

Ah, ok, so you implemented the separate player task finally... nice I didnt discover it for the latest version, as I seldom use TuneNet menu once I started playback. I only saw it with the older version (dont remember which one).

Well, I think its not really about ReAction and MUI, its about locking the whole screen, resp. missing "sprites" for display dragging actions. ReAction gadgets lock the screen if they update their contents and MUI needs a previously unlocked screen to display the dragging action. So it breaks the dragging action in case the screen is locked at any time the dragging action takes place. Do I see this right?

I had a similar issue with Workbench dragging, I solved this by checking the screen if its locked and if its locked, I stepped over GUI update until the screen is unlocked again. Its not perfect (race conditions still possible), but quite ok.

I think we have to wait for a solution that permits drawing in the background resp. layer-dependend drawing, so that a program doesnt need to lock the whole screen for actions that take place in a specific layer only...

Edit: Another idea traveled through my brain as I read my text again... what about implementing dragging with a "moving layer"? This way layers.library would be able to reconstruct a layer needed by a gadget in a temporary way, until the moving "dragging object" is out of layer range... its really a pity that sprites where dropped back then

@whose

Heh heh, TuneNet has had seperate processes for playing for at least 3-4 years! (if not longer)

I believe if you use the SkinFX mode in TuneNet then you won't have any locking issues. I look into checking for a screen lock for the Reaction mode, thanks for the tip.

Cheers,
Bean

I've found the same with my AmiTunes application which updates a slider to show the current position in the song. It only uses GadTools, but even then it will abort DnD operations on the Workbench itself. Took a good bit of working around the issue (not to mention hair pulling!) to get it to work eventually.

If DnD were implemented using compositing, all these problems would go away, because dragging something on a separate surface would never get damaged by anything above or below it...