Thanks for the patch.
Actually I wanted to do this last night but I don't have the time.
Previously I did direct member access for performance reason.
This can save tons of function calls.
Though the speed difference is not visible to the users, having many additional function calls which can simply be avoided makes me "very" uncomfortable.
So the plan is using direct data member access inside the library, and prohibit direct access from outside programs. I deliberately kept the struct member visible just to reduce unnecessary function calls.
To prevent its use outside the library itself, we have an easier way.
See what glib have done with GSEAL(). Its a nice way, I think.
I'm not a fan of adding getter and setter functions for everything.
But in this case, directly access members of FmFileInfo indeed causes some problems.
I'm going to apply your patch later after a review.
Thanks a lot.

On Wed, May 23, 2012 at 10:32 PM, Andrej N. Gritsenko <> wrote:
   Hello there!

   Since direct manipulation of some members of structure FmFileInfo is
dangerous, can be misinterpreted or led to crash, direct access should be
prohibited. In some places of libfm there is no direct access but APIs
fm_file_info_* are used but in some places there was still direct access.
To avoid it I've moved the structure into src/base/fm-file-info.c and
modified all direct access (where it still was) to indirect (via APIs
fm_file_info_*). Patch is in Patches tracker:
   I would appreciate all your opinions and hope that cleanup will be

   With best wishes.

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Pcmanfm-develop mailing list