Possible bug in Linux DesktopTextField?

Targets Linux
1

Code for a DesktopTextField

Sub DropObject(obj As DragItem, action As DragItem.Types) Handles DropObject
  Me.Text= obj.FolderItem.NativePath.Trim
End Sub

Dragging and dropping adds a space and this odd return character to the end:

Screenshot from 2024-12-04 23-09-34
Screenshot from 2024-12-04 23-09-34590×286 18.5 KB

Bug or am I doing it wrong?
Linux Mint 22 just in case it is working on another distro differently

2

I’m wondering why the .Trim is necessary. Folderitem.NativePath is returned by Xojo. If the user were copying that string to paste elsewhere, and being perhaps loose in their selection, that’s when you might want to trim it.

3

I did it to try and get rid of the space and return looking character. ultimately it does nothing to help and hurts nothing. Plus paths do not and should not end in whitespace so it is good to have.

Plus in this instance Xojo Folderitem.NativePath is returning bad characters so it might be needed!

4

Again, why trim whitespace that you know is not there? Anyway, this sounds more like a text encoding problem.

5

Technically I 100% know there is a space being added
 It is apart of the problem statement.

I will try the encoding idea though, that’s a possibility. Thanks

6

I’m touching base to see how you are doing.

I did a simple test project on Mac. For me (as expected), Folderitem.NativePath does not return whitespace on the end. As to my encoding idea, I would have been surprised if it were not returning UTF-8. Again, I was not surprised.

So yes, per your subject line, this is smelling like a Linux thing. I think I will play with that idea later, as I am sincerely interested in this and will certainly support any ticket you might open. My VM farm does include Mint 22, so I can start with that. :slight_smile:

7

Here is my sample project. I’ll play on Linux later, but it’s bedtime. I hope this helps (Edit: unless you’ve already licked it. :slight_smile: ).

Note that I have included a text file. It is a hard-coded folderitem (unless you do the drag and drop option), so place it on your desktop.

Unless you’re also a beta tester, you will likely get the “newer version” warning, which should not be a problem.
TextField test.zip (8.9 KB)

8

It Is only drag and drop that does this for me. All other instances of using folderitems in my history of using Xojo has not added these characters to the end.

That is the link to my project, it is open source. If you browse for a file then no characters are added. Its very odd.
I did make an issue https://tracker.xojo.com/xojoinc/xojo/-/issues/78020#note_588418

It seems that Ubuntu doesn’t have the same problem so it might be an issue between Xojo and Mint.

9

Hi, can confirm the issue.

Running Linux Mint 22, I ran your test code and see the same character.
Here’s a screen shot

Screenshot from 2024-12-07 14-35-47
Screenshot from 2024-12-07 14-35-47600×361 35.6 KB

10

Do you only get it with drag and drop, like Paul reports? I will be able to test myself in a little while.

11

Yes, only drag & drop. I used the ‘Test’ button and here’s the output

Screenshot from 2024-12-07 16-09-09
Screenshot from 2024-12-07 16-09-09620×377 30.7 KB

12

Ah, but when I just sat down with it in the light of day, I found a mistake. The pushbutton code does not actually populate the Textfield. I had inadvertently removed 'TextField1.Text=myFolderItem.NativePath" while doing other editing (just before turning in.)

I wrote the example on my laptop last night, but now am at my desktop machine in the light of day. I already happened to have a Gentoo VM already up, and I can reproduce Paul’s issue myself. And now that I fixed the pushbutton code, it is clearly only drag and drop. I will try other distros, but I can tell you right now that it’s not just Mint.
TextField test.zip (8.1 KB)

13

In the meantime, I found a workaround. Add this to the TextField’s TextChanged event handler. Paul, you were on the right track with the Trim, but doing it too soon. :slight_smile:

Me.Text=Me.Text.Trim
14

Better than that, here is the revised project. I have removed the messageboxes, because that information (end of the string and encoding) proved not to be the issue.

I have since tested on Mint 22 myself and, as with Gentoo, have confirmed what Paul is getting. To try the workaround, un-comment the line in TextField1.TextChanged
TextField test.zip (8.6 KB)

1 Like
15

I’ll try this workaround tonight! Thanks for looking into it. If you guys haven’t already comment on my issue so the people at Xojo know it isn’t a 1 off instance.

Did your Gentoo system have Cinnamon installed as the DE? Or something else?

16

I’m running Cinnamon. Added comment to the issue.

1 Like
17

I have have two Gentoo VMs. One is stable (legacy BIOS) with XCFE. The one I originally tested was the cutting edge one (with EFI). That did in fact have Cinnamon.

Meanwhile, I appear to have solved the whole thing–WITHOUT a workaround. First, after confirming your issue on Mint and Gentoo, I got a separate one on Debian 12: drag and drop appended a “file:///” prefix to the file name. That was weird, but maybe a clue.

The real clue game when I tried all of the Ubuntu distros (Ubunti? :slight_smile: ), and drag and drop did not work AT ALL. Same with Arch. It was then that I realized that, in the TextField’s Opening event, I should have defined a file type for me.AcceptFileDrop. Mac didn’t care, and the distros we were first looking at did what they did.

I did so (“text/plain”), and everything worked everywhere.

I have commented (and voted) on your issue, and added comments already. Now I have to do another one.

So yes, this yet-again revised sample project might help. Note that is has a FileTypesSet that gets referenced. I hope this helps. Weird, though that you did not see the problem I did on Ubuntu.
TextField test.zip (8.8 KB)

1 Like
18

I’ll try this too but with image files and what would an executable (no extension) file be considered in Xojo terms?

19

Just out of curiosity, are you guys sure that the DropObject event is firing? I could see this being a function of the OS in that the field probably natively accepts text drops and a dragged FolderItem could be represented as text. It may just be a coincidence that it happens to show a native path.

2 Likes
20

Ah yes, silly of me to focus on text files. :slight_smile:

Create a FileTypeGroup. In the IDE, there is a pulldown menu to select common ones. Choose “special/any”. After selection, you will notice that the extension field contains a wildcard *.

Then, in TextField.Opening, do

Me.AcceptFileDrop(FileTypeGroup1.Any)

You should now be able to drop any file, and of course the TextField only cares about the NativePath.

Offhand, I don’t know of anything other the wildcard, if you wish to drop executables. Otherwise, populate the group with all relevant image types. Then you might do

Me.AcceptFileDrop(FileTypeGroup1.All)

PS: My one VM I hadn’t yet tried was OpenSuse Leap 15.6. I retroactively ran the older, problematic build of my example on it and got the same “file:///” prefix error as Debian. Both have Platinum desktops, which leads me to believe that Cinnamon was indeed the common factor for me on Mint and Gentoo.