In a similar vein to displaying EXIF data for JPEGs, display data from PNG chunks for PNG image files. Various chunk types are listed in the PNG specification here: http://www.libpng.org/pub/png/spec/register/pngreg-1.3.0-pdg.html In particular, display the tEXt and zTXt chunks in a suitable property page. I'd have a go myself at this, but not being familiar with GTK nor XFCE programming it would take me longer than an expert. If someone were to give some hints, I'd be grateful. (Downloaded the GIT repository for XFCE, built it, no further yet.)
I presume that in "thunar_apr_image_page_file_changed(...)" I can open the file using "filename" using the libpng library, get the image info I want, and populate it into a page in a similar fashion to the way that the EXIF data is done? Is that reasonable?
Created attachment 5136 Example of the extended Image tab to show chunk information from a PNG file. Here's an example image of the output of the modified code I created to give you an idea of how I managed to make it look. I've never used GTK before so it is not pretty, but works.
Created attachment 5137 Patch file with code that implements ability to read chunk data from PNG files. Here's my suggested, initial, patch to implement the requested functionality. Notes: 1. I've never used GTK nor coded for XFCE nor Thunar before, so forgive my formatting errors. 2. I've tried to add the functionality in a library-style. I don't think the added functionality (in thunar-apr-png-read-data.*) should be in a separate .so because it's not really general enough. Also I'm not familiar enough with cross-platform coding (*nix/Win) to do this. Nor am I familiar enough with autotools to do this on *nix alone! 3. I didn't follow the Exif style of 2 columns & emboldened first column for a few reasons: a) Although the chunks are finite in number, the chunks are usually optional (apart from IHDR) so the sub-table I put them in has a variable number (up to a maximum) of rows, which is why they are all put in a scrollable sub-table. b) This sub-table has only one column, because the number of key-value fields in the tEXt chunk is also variable, and the key-values are arbitrary. c) Most importantly I'm not familiar enough with *nix/Win cross-platform coding to make use of a pre-existing linked list to plonk all this variability in, hence I just made an array big enough to hold all possible chunks. (There's less than 50 of them, and the number has remained stable for nearly a decade.) 4. If libpng is not found, then following the Exif implementation, this should all be #idef'd out. 5. I didn't set Atk label relations for the PNG labels because I haven't a clue what they do nor if it is relevant: ignorance on my part. Sorry.
Created attachment 5138 Fixed a bug in the previous patch that meant that the scrollable viewport was always visible. Please apply this after 5137. Sorry for the inconvenience.
Created attachment 5139 Add exo and Atk bindings to the PNG table. Also extract the row names to make them fit in better with the header & Exif style of display. Realised that the point I made about Exo & Atk bindings was not reasonable. I fixed this and now the PNG items have row names in a similar style to the Exif ones, so the PNG data looks more like the Exif one, so a more uniform UI.
Created attachment 5140 Add support for more chunks. Added support for more PNG chunks.
Created attachment 5141 Added sCAL support. Added sCAL support.
Created attachment 5142 Ensure that we only add uncompressed text at the moment, as we don't handle compressed text yet. Ensure that we only add uncompressed text at the moment, as we don't handle compressed text yet.
Created attachment 5143 Pants. Fix a minor compiler warning about unused variables; I like clean compilations. Sorry - yet another patch. Minor: I don't like unclean compilations. Remove minor warnings.
If I knew how to make git roll all of these patches up as one patch, to make life easier I would...
I noticed that in the PNG info GTK_SCROLLED_WINDOW I introduced, if scroll bars appear, the mouse cursor is not the arrow cursor, but the text insert cursor on the scrollbars, meaning you can't use them with the mouse! I'll try and figure out how to fix this, but if you can advise, I'd be grateful.
Thanks for all the patches Jason. I'll try and review them after 4.12, and I'll let you know if any changes or fixes are needed.
Thanks for that, it would be very good to have this additional functionality. Please feel free to ask me regarding any issues/queries you have & I'll try to assist.
Created attachment 7619 squash of all previous patches - tried to apply to current master, but failed :( - Will need some love to compile again since "gtk_table" meanwhile was replaced by "gtk_grid" - fixed patches to work for current master and squashed all into one for better handling ( patched plugin does not compile ! )
Created attachment 7621 squash of all previous patches patch now works with master However it will need alot of polishing before it can be accepted Generally I am not sure if we want to add that much code for that little gain at all. If I open some random png, the only extra-info I get is: bit depth=8, colour type: RGBA, interlace type: none RGB=(8, 8, 8), gray=0, alpha=8
For why this could be added: At the time this request was created, *no other program* would show the technical details of a PNG, otherwise I would not have created the patch! Today Ristretto v0.6.4 does not show those technical details. Gimp v2.10.8 shows, frankly, inaccurate details... (!) Okular v1.7.3 & feh v3.1.1 does not show any technical details at all. So as you can see: there is a "region of missing functionality" here that Thunar could fill... As Thunar shows EXIF details, surely PNG technical details should be shown too. Frankly I think this is the killer argument to support this functionality. (libpng allows read-write access to these chunks at a basic source-code-level.) It has been suggested that this could be implemented as a thunar plugin. (And the EXIF functionality could be made into a plugin too, but that is outside the scope of this request.) I have no opinion on this matter as I am no expert in the design of thunar and would gladly receive advice. Any TODOs are there on purpose: there is missing code and it is trying to indicate that advice is needed! The reason that this patch has not been applied to HEAD is that Gentoo uses Thunar v1.6.16 (somewhat old!) and I could not get HEAD to run on my Gentoo laptop, so developed against a version I knew I could get to run..
> patch now works with master Thanks a lot! > However it will need alot of polishing before it can be accepted > Generally I am not sure if we want to add that much code for that little > gain at all. > If I open some random png, the only extra-info I get is: > > bit depth=8, colour type: RGBA, interlace type: none > RGB=(8, 8, 8), gray=0, alpha=8 I am not surprised. In my experience support for PNG chunks is somewhat "limited" to be polite and often buggy.
Thanks for the bump ! > I could not get HEAD to run on my Gentoo laptop, so developed against a version I knew I could get to run.. To build &run thunar master is required for further development. What is the error you encountered ? Please send me a private mail, or idle in IRC / #xfce-dev to get support on that. I as well never wrote a thunar plugin myself. IMO it is a good idea to start with an existing, working plugin which uses the same Interface we want to use. I adviced to look at rabbit-vcs, which uses python .. not optimal, since we want to use C-API. I recently learned that the thunar-media-tags-plugin is a much better starting point: https://git.xfce.org/thunar-plugins/thunar-media-tags-plugin/ IMO the steps should be: - first get the media-tag plugin to compile & and run from source - Strip off all code which we dont need, and check that it still runs - Drop the media-tag git history and start a new git project/history with that base - Rename the remaining files / methods / etc. to reflect our purpose, and check that it still runs - Step by step add PNG / EXIF info to the extra property page ( Afaik Nautilus uses the same, or at least very similar plugin API .. so if you later want to further spread the plugin, this should be feasible )
One downside: Currently the media tag plugin seems not to work for me .. maybe I do something wrong .. could you please take a try to see if it works for you ? A .mp3 file with a id3 TAG afaik should be sufficient. So possibly we would need to debug it first :) Afaik thunar-media-tags-plugin makes use of exactly the feature we want, an additional property page: It does that by implementing the interface THUNARX_TYPE_PROPERTY_PAGE_PROVIDER: https://git.xfce.org/thunar-plugins/thunar-media-tags-plugin/tree/thunar-plugin/media-tags-provider.c#n59 Ah, wait, silly me, forgot what I said abaout the "steps we should do" in my last comment. Actually pictures are as well media .. how about just extending the media tag plugin with PNG / EXIF information instead of adding a new plugin ? That would be simpler, and would require less maintenace effort afterwards !
(In reply to alexxcons from comment #19) > last comment. Actually pictures are as well media .. how about just > extending the media tag plugin with PNG / EXIF information instead of adding > a new plugin ? That would be simpler, and would require less maintenace > effort afterwards ! Great plan! :) I shall follow your advice, but initially with the older version of thunar to "get it working". Then I shall attempt to port to master (which as I misleadingly noted does not work on my Gentoo XFCE v4.12-r1 system with thunar v1.6.16. IIRC: with master thunar's dbus connectivity whinged. I then compiled without dbus and "worse things" happened, so gave up on master.)
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/57. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev