After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 578829 - File Browser plugin can only show files with no extension on Win32
File Browser plugin can only show files with no extension on Win32
Status: RESOLVED OBSOLETE
Product: gedit-plugins
Classification: Other
Component: General
2.26.x
Other Windows
: Normal major
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 606423 640142 668735 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-13 12:59 UTC by thomasrutter
Modified: 2020-11-24 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Correctly detect whether content type is text on windows (1.88 KB, patch)
2011-01-11 15:03 UTC, jessevdk@gmail.com
none Details | Review

Description thomasrutter 2009-04-13 12:59:40 UTC
Please describe the problem:
Using gedit Win32 build from:
http://ftp.gnome.org/pub/gnome/binaries/win32/gedit/2.26/gedit-setup-2.26.0-1.exe

The file browser plugin only displays files with no extension, ie 'Makefile', and does not show any files which have an extension, ie 'try.c'.

Steps to reproduce:
1. Open file browser with F9 and switch to file browser tab
2. Navigate to a folder that you know contains source code files



Actual results:
No files shown, unless they have no extension (ie 'README' or 'Makefile').

Expected results:
All files shown

Does this happen every time?


Other information:
Changing 'Match filename' box at the bottom doesn't seem to help.  Seems to default to '*', which exhibits the problem.  Changing this to '*.*' does not help.  Showing/hiding hidden files does not help.

Problem also occurs on the 2.25 builds.

If this isn't the appropriate place to report win32-specific builds could you please suggest who I could contact - thanks!
Comment 1 Ignacio Casal Quinteiro (nacho) 2009-04-13 15:59:57 UTC
Here it is ok, could you try if showing binary files and hidden files solve your problem? (Right click->Filter)
Comment 2 thomasrutter 2009-04-14 09:26:19 UTC
Ah, after right clicking and turning on Filter -> Show Binary, files with extensions are now shown.

Note that the 'Show Hidden' option did not help, but this has.

It seems like any file with an extension is treated as binary and not shown by default in Win32.

More info:
Windows XP professional SP3
Also not sure if it's relevant, but I have other GTK based applications installed on the same machine.

Cheers
Comment 3 jessevdk@gmail.com 2009-04-14 11:01:20 UTC
This is a known issue and has to do with how gedit detects whether something is a binary file or not (by using mime type). On windows it needs to compare to a different kind of mime type to decide if the file is considered text or not, and I guess this is not yet correctly implemented?
Comment 4 Ignacio Casal Quinteiro (nacho) 2010-01-08 15:59:23 UTC
*** Bug 606423 has been marked as a duplicate of this bug. ***
Comment 5 jessevdk@gmail.com 2011-01-11 15:03:40 UTC
Created attachment 178040 [details] [review]
Correctly detect whether content type is text on windows

Possible solution for the problem. This patch is untested but the idea should be clear. If someone with windows access could test it?
Comment 6 Ignacio Casal Quinteiro (nacho) 2011-01-11 18:19:12 UTC
Review of attachment 178040 [details] [review]:

I feel that this patch will still make detect only files with .txt extension in windows. Maybe we should do like pbor said and get the extensions from gsv see if any of them matches the files. Although I feel like this would be quite expensive.
Comment 7 jessevdk@gmail.com 2011-01-11 18:34:01 UTC
Why do you think that? If you look at the g_content_type implementation and the windows registry, then this would work for quite some files.
Comment 8 jessevdk@gmail.com 2011-01-11 18:40:32 UTC
I've pushed the patch after fixing a little typo. It's not tested on windows (although I think it would work). I'm leaving the bug open until we have verified that the problem is actually solved.
Comment 9 jessevdk@gmail.com 2011-01-21 11:59:07 UTC
*** Bug 640142 has been marked as a duplicate of this bug. ***
Comment 10 Ignacio Casal Quinteiro (nacho) 2012-01-28 13:32:35 UTC
*** Bug 668735 has been marked as a duplicate of this bug. ***
Comment 11 Sébastien Wilmet 2020-11-24 10:17:56 UTC
Mass-closing of all gedit-plugins bugzilla tickets.

Special "code" to find again all those gedit-plugins bugzilla tickets that were open before the mass-closing:

2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3

By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements.

We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.