Irritatinf warnin message

I'm triyng to write a simple GUI for system command plocate with a context menu for some actions on a selected item.

I always get that warning: "gb.desktop: warning: FindMime() is deprecated, use FromMime() instead." in Konsole window of the IDE in Gambas 3.19.6, though I never use the method FindMime in my code.

Any guesses?

John Blackcrow

I'm guessing this shows in the IDE console when running your application.
It is probably some output of an underlying library, used by gb.desktop component. That library has had changes since the 3.19.6 release of gb.desktop, that cause this output

Guesses?
I guess you application works just fine and you can ignore this output.  

.

Thank you for your anwser.

I forgot, that I discovert another inconsistency with the DesktoMime component: it returns mime type application/x-executable when requesting property Type for directories, which is not conform to XDG standard.

The output of CLI command:

correctly returns inode/directory. This happens with all versions of Gambas I tried, inlucing the last version available for Debian Bookworm: 3.20.


So, for /home/username/.locare/share/applications,

Prints: application/x-executable

John Blackcrow

Inode/directory is not a type Gambas handles.

Use IsDir to separate files from folders.

If IsDir(sPath) then
  ' do dir stiff
Else
  ' do file stuff
Endif

The depreciated FindMime warning is internal.
Some gb.desktop commands used to use the deprecated FindMime method.

It should be fixed in new gambas versions

BruceSteers said

Inode/directory is not a type Gambas handles.

Use IsDir to separate files from folders.

If IsDir(sPath) then
  ' do dir stiff
Else
  ' do file stuff
Endif

The depreciated FindMime warning is internal.
Some gb.desktop commands used to use the deprecated FindMime method.

It should be fixed in new gambas versions

From “Post #12,404”, October 10th 2025, 9:11 AM

Thank you,

it is clear, that there are many possible ways to work around this inconsistency. I'm using the Stat Function in my program to display size and date of items, which allows to use

But the class DesktopMime is designed by definition in the documentation to handle the file mime database as defined in Freedesktop Standard, which it definitely doesn't do correctly.

The documentation of it unfortunately is nearly useless, because it just documents the FromFile and GetApllications method. Everything else is missing any detailed description and invites you to do the best programming practice nowadays known: hours and hours of trial and error. I don't like that style so much.

Ok but consider this…
DesktopMime.class has the FromFile method.
and FindMime and FromMime are part of DesktopFile.class

The operative word there being "file" meaning they are all file specific.

I get what you are saying, I searched the gb.desktop code for some time to find the bug that did not show inode/directory but what i discovered was it simply is not supported.

I think from the gambas developers point of view it was not needed as IsDir() and other methods can be used.

If you have issues you could always join the gambas mailing list and Benoit would explain the reasoning for not supporting directory mimetype.

Although to be fair Benoit did not write gb.desktop, when i first started using gb.desktop i found supporting Actions (DesktopFile.AlternativeActions) was very bad and not usable.
I wrote the DesktopActions.class (DesktopFile.DesktopActions) but did not write any other gb.desktop stuff.

Btw directory is only "not detected" as a file mimetype.

inode/directory is supported in other ways by DesktopMime.class

Try this…

Dim aDF As DesktopFile[] = DesktopFile.FromMime("inode/directory")
For Each hDF As DesktopFile In aDF
  Print hDF.Path
Next

Thank you, BruceSteers

BruceSteers said

Ok but consider this…
DesktopMime.class has the FromFile method.
and FindMime and FromMime are part of DesktopFile.class

The operative word there being "file" meaning they are all file specific.

In Unix / Linux, there is no such thing as file or directory, but everything that could be read or written, are streams. That's the reason for Mime Types to classify the possible properties and actions of a stream. The strict separation between file and folder or directory as different item types come from other operating systems.

I get what you are saying, I searched the gb.desktop code for some time to find the bug that did not show inode/directory but what i discovered was it simply is not supported.

I think from the gambas developers point of view it was not needed as IsDir() and other methods can be used.

May be, that's the case from gambas developers point of view. But if so, then the documentation of Desktop Mime as interface to the Freedesktop.org Mime database is wrong.

If you have issues you could always join the gambas mailing list and Benoit would explain the reasoning for not supporting directory mimetype.

I didn't want to criticize the great work of Gambas in general. I'm sure, there is a good (internal) reason for this inconsistency. But from the compatibility point of view with the specs of freedesktop.org, in my opinion this shout be kept behind from the Type property of DesktopMime, instead of returning application/x-executable, because that's not true.

That is the major cause of lots of trouble in Linux and all its components like Desktop Environments, Software and programming languages to become more accepted in general. Another reason is the fundamental lack of availability of detailed, accurate, and complete documentation for Linux.

Most programmers may have some good internal reasons to break general specifications like those of freedesktop.org for some special cases, but those exceptions should be handled inside of their components.
The handling shouldn't be directed to the users of a component or system, which unfortunately is very often the case in Linux and causes many unexpectable trouble in everyday life and lots of necessary manual workarounds.

I understand that very well, because as coder, I'm also focused on the functionality of my work and sometimes forget the whole thing it is part of.


That is not only a question of philosophy, but has practical influence to the user experience and acceptance of systems like Linux in general.

Although to be fair Benoit did not write gb.desktop, when i first started using gb.desktop i found supporting Actions (DesktopFile.AlternativeActions) was very bad and not usable.
I wrote the DesktopActions.class (DesktopFile.DesktopActions) but did not write any other gb.desktop stuff.

From “Post #12,419”, October 10th 2025, 3:19 PM

Nice work, thank you.

John Blackcrow