Add CSS styling support #104
Conversation
|
Very nice work ! =D |
| pub fn load_from_path(path: &str) -> Result<CssProvider, glib::Error> { | ||
| unsafe { | ||
| let pointer = ffi::gtk_css_provider_new(); | ||
| let mut error: *mut glib::ffi::GError = ::std::mem::zeroed(); |
There was a problem hiding this comment.
This can simply be let mut error = ptr::null_mut();
There was a problem hiding this comment.
It should be let mut error = ptr::null_mut();.
There was a problem hiding this comment.
Ah, I was looking for how to do that. I saw ptr::null(), but missed ptr::null_mut().
|
Since you use The reference counting isn't handled well but I guess this will be fixed by the objects reform. If the minimum GTK version for a method or class isn't specified it's safe to assume that it's present in GTK 3.4, which is the lowest version we support (also 'since 3.0' and 'since 3.2' can be ignored). |
|
Ok, fixed. One more question: The |
I believe a lot of the definitions currently assume that |
Should I add another variant called |
It would not be a C-like enum any more so you'd lose any conveniences and some derived traits. And anyone could put |
|
Ok, I think I'll change the type to a |
|
Ok, I added the constants. You can access them with |
|
I also just added a commit that documents the priorities. I copied the documentation directly from the Gtk docs. |
| /// The priority used for default style information that is used in the absence of themes. | ||
| /// Note that this is not very useful for providing default styling for custom style classes, | ||
| /// themes are likely to override styling provided at this priority with catch-all * {...} rules. | ||
| pub const PRIORITY_FALLBACK: u32 = 1; |
There was a problem hiding this comment.
The idiomatic approach would be to define GTK_STYLE_PROVIDER_PRIORITY_* constants in the sys crate (those definitions will become autogenerated eventually) and use those on the right hand side here.
It looks like we're going to reexport all symbols in the top namespace and the names would have to be longer in that case, e.g. We may want to investigate using associated constants -- they seem to be available in the nightlies. Example: https://github.com/rust-lang/rust/blob/master/src/test/run-pass/associated-const-inherent-impl.rs |
Why not just use proper namespaces?
StyleProvider is a trait here, so it wouldn't work. Maybe after object reform? |
Err, actually if you can provide default values for constants (which wasn't in the documentation), than we could do this. |
Some reasons here: gtk-rs/glib#47 (comment) It may just be a fool's errand to try to add structure to all of GTK because it's too diverse. While converting every module to the new framework I find it very difficult to organize them coherently. An arbitrary mediocre structure may be worse that the flat convention. |
|
I guess, we could also just have a flat series of modules ( |
|
Ok, I just left them as normal constants. |
|
I guess we can reexport these consts in the root module now. Otherwise seems okay to merge. Small style nits I'd just tweak in the process of refactoring. |
|
Oops, forgot to reexport. Fixed. |
Add CSS styling support
This PR adds CSS styling support by implementing
CssProvider,StyleProvider, andStyleContext. An approach similar to that used withWidgetTraitwas taken.get_screenis also implemented forWidgetTraitso this screen can be used withStyleContext::add_provider_for_screen.There are some TODOs in the code for adding the proper
#![feature]attributes. The Gtk documentation doesn't give this number for every method/class, and I think this is due to a lack of documentation, not the fact that the method/class was introduced before gtk3. How should I find these feature numbers?