Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Background: Use GLib.File instead of dealing with Paths #1711

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

tintou
Copy link
Member

@tintou tintou commented Jul 4, 2023

Simplify the code and avoids to deal with File paths directly.

Simplify the code and avoids to deal with File paths directly.
@tintou tintou mentioned this pull request Jul 4, 2023
@tintou tintou requested a review from lenemter July 6, 2023 08:57
Copy link
Member

@lenemter lenemter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we omit the GLib namespace? It makes some lines pretty long.

@tintou
Copy link
Member Author

tintou commented Jul 6, 2023

I personally really prefer having the GLib namespace specified (when it's not a native type like string/int/bool) so that we know that it is not an object from the project but from GLib

public string filename { get; construct; }
public string[] key_frame_files { get; private set; default = {}; }
public GLib.File file { get; construct; }
public GLib.GenericArray<GLib.File> key_frame_files { get; private set; default = new GLib.GenericArray<GLib.File> (); }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be a GenericArray? given that we known that the max number of files we will use is 2, isn't a fixed array enough.


this.key_frame_files = key_frame_files;
this.key_frame_files = new_key_frame_files;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think the this accessor is needed anymore here.

}

construct {
background = new Meta.Background (display);
background.set_data<unowned Background> ("delegate", this);

file_watches = new Gee.HashMap<string,ulong> ();
file_watches = new Gee.HashMap<GLib.File, ulong> ();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use GLib.File.hash and GLib.File.equal here? Gee will fallback to direct_{hash,equal} if the functions aren't provided here.

Comment on lines +125 to 126
if (file_watches.has_key (file))
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code style.

Suggested change
if (file_watches.has_key (file))
return;
if (file_watches.has_key (file)) {
return;
}

else
load_image (filename);
private inline void load_file (GLib.File file) {
if (file.get_basename ().has_suffix (".xml")) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we should use GLib.ContentType.guess() here, so that we can identify xml files without a extension. like the ones that the Gtk portal provides.

}

// Animated backgrounds are (potentially) per-monitor, since
// they can have variants that depend on the aspect ratio and
// size of the monitor; for other backgrounds we can use the
// same background object for all monitors.
if (filename == null || !filename.has_suffix (".xml"))
if (file == null || !file.get_basename ().has_suffix (".xml"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing here, should check the mimetype instead of extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants