Ability to drag/drop media (disks/roms)

[oh-ren]

Window 7, but may also apply to other OS's.

It would be neat/handy, and an improvement in usability (IMO) to have the ability to drag & drop a dsk or rom (from e.g. Explorer) into Catapult (I reckon the Disk/Cart input/dropdown field is appropriate for this).

[MBilderbeek]

Actually, this should already work, but it seems it's not entirely perfect :) If you drag and drop on e.g. the disk A combobox, the item gets added to the list, instead of directly filled in. So, drop down the list and you'll see it at the end...

I'll try to improve it a bit.

[MBilderbeek]

Can you at least confirm it's working as I described?

[oh-ren]

Hi, Sorry for the late reply!

Yes, I can confirm it's working as you described. It get's added at the bottom (even if it's already in there). It also seems it doesn't check file type or extension, I can drop anything in there :) The added (superfluous) drag-drop entries are gone when Catapult is restarted.

[MBilderbeek]

OK, so should I change something? Should dropping just put the dropped file on the input box? I don't think we should check for extensions, because you never know what extensions people use for disk or ROM files. Also, checking the file type itself is not easily implemented, I think.

[oh-ren]

Not forcing a file extension is ok/good I think. Checking if an inserted file is actually a valid disk or ROM image is a different story of course.. (but would be cool nonetheless..) :)

IMO it should behave the way it is when selecting a file via the browse dialog (so yes, immediately shown in the input box as the selected file). Currently, I just discovered, it also makes Catapult crash when actually selecting the added entry in the dropdown.. Of course it doesn't make sense to drag/drop something, and then having to navigate down the list to select it..

On a related note, I think it would also be cool if one could drop files on the openMSX window itself (while running). Perhaps a rmb (or +Ctrl) drag/drop could then mean 2nd drive or slot (determining the file type by it's extension). I could also imagine an OSD drop target popping up when entering the window with a dragged object :)

[MBilderbeek]

How could that validity be checked?

I'll make the change to let the drop cause directly the file to be shown in the input box. After this change, it seems the crash is also solved. Probably next build on the openMSX Builder site will have it :)

I don't think that libSDL 1.2 supports drag-and-drop, so that is not possible at the moment. When we switch libraries, we can consider that again.

[oh-ren]

How could that validity be checked?

Well, for disks that mustn't be that hard, those can be easily(?) recognized (header boot sector) (+ file size)? ROMs are more difficult I guess, but then the romdb can be used and/or checked if the file size is a common ROM file size and/or a multiple of 8K? Isn't currently already mapper guessing applied when an unknown ROM is loaded?

By valid I don't necessarily mean the image/file being without errors or something.

I'll make the change to let the drop cause directly the file to be shown in the input box. After this change, it seems the crash is also solved. Probably next build on the openMSX Builder site will have it :)

Alright, cool :sunglasses: Will it also handle the duplicate thing, and be remembered after restarting Catapult?

I don't think that libSDL 1.2 supports drag-and-drop, so that is not possible at the moment. When we switch libraries, we can consider that again.

Cool again ;) Is there more known already in regard to this move from libSDL?

[MBilderbeek]

The ROMdb and mapper guessing is all done in openMSX, not in Catapult. Catapult is really quite dumb (actually, it's already too smart). Anyway, such recognition isn't going to be 100%, so that won't really help anyway. Plus, as I said, this shouldn't be duplicated from openMSX in Catapult.

In other words: I don't think it's worth it. And if it would be, it should be done in openMSX first and not in Catapult. So if you want to check validity in Catapult it should somehow ask openMSX for that. All of this could be more easily done once we have a GUI integrated.

About your questions on the duplicate and remembering thing: please try it out, the new build is on the openMSX Builder site.

There's not much to say about the move from libSDL, as no one is currently actively working on it.

[oh-ren]

Thanks.

such recognition isn't going to be 100%, so that won't really help anyway.

I don't want to conclude it won't really help myself. For most (common) stuff it will work I reckon. Good enough.

Again I hear about plans for creating an integrated GUI, and thus replacing Catapult. Would be really cool if you could mention plans like this in (something of) a roadmap (or perhaps it's in the issue tracker already, perhaps such issues can be tied to a milestone?). Good for everyone to know your plans regarding that, so we can perhaps also conclude not to expect a lot more (ground shaking) new functionality from or work on Catapult. (I guess I won't really bother with new Catapult feature requests then.. ;))

I'll try out a new dev build once it's available.

There's not much to say about the move from libSDL, as no one is currently actively working on it.

There must be some plans though? What are you planning to move to?

[MBilderbeek]

The point is, if the recognition isn't 100%, Catapult would refuse stuff the user knows is working fine. That's more annoying than having it refuse stuff that was mistakenly not fine. Refusing stuff that it shouldn't makes it unusable for that stuff, but if you just insert a wrong file, you simply get openMSX or the MSX disk ROM to ignore the disk image.

As of 2007 we have put in the release notes of Catapult that there is no active development on it. Unless they're really easy, it's not likely we will implement new features on it.

We don't do milestones, as we don't have planning. Also, roadmapping is not really worth it at the moment. We only know that at some point we'll leave SDL, that's all.

The dev build is already available for about 2 days. :) (There's a new build soon after each commit.)

Currently the idea is that we move to a Qt based GUI, but nothing has been set in stone yet, as (again) no work was done on that concretely.

[MBilderbeek]

By the way, the best way to get updated on current openMSX internal discussions, is to join our IRC channel, #openMSX on the FreeNode network.

[MBilderbeek]

So, did you try it already?

[oh-ren]

:) (I can be such a lousy bum.. Replying again after 10 days.. ;)) (Only just now noted your question..)

No, I haven't tried it yet. I did have the latest build when we discussed it - I guess the build bot/script only monitors the openMSX repo and not this one? Anyway, will come back on you soon.

• Thanks for the IRC invite, have never been much of an IRC guy though, but I might go an a venture.. ;)

[MBilderbeek]

The new build was available about 22 days ago...(within a day or so after we discussed it) so please try it :)

[oh-ren]

Some observations:

• dropped media isn't remembered (history);
• when opening+closing dropdown after item has been dropped, selection will revert to the item selected/active before drop (item goes 'missing' from list (<> next bullet));
• no superfluous items are created anymore (so that's good), but now actually nothing is added to the dropdown at all.

I did see the relevant commit, which is a simple change of using SetValue instead of Append (so I didn't expect too much already.. :wink:) Isn't it possible to process a dropped file like it has been added via the file browse dialog? I guess/reckon then the behavior is like it should / is desired..

[MBilderbeek]

OK, you're right. I fixed it in commit ac8efbef720eb1979602a7cba9047de5f55f69a1 Please test. Build is probably ready soonish.

[MBilderbeek]

Should be available now.

[MBilderbeek]

Can this ticket be closed?

[oh-ren]

Hey, yes closing it now, seems to work fine, thanks!