Age | Commit message (Collapse) | Author | Files | Lines |
|
with help from Alexei Sorokin
|
|
with help from Alexei Sorokin
|
|
|
|
|
|
also en_US isn't a translation at all
|
|
|
|
|
|
|
|
|
|
|
|
The Caja information panel (information option in sidebar) was never fully ported to GTK3, probably still isn't. Set the .view style class on it, and exclude the rest of caja_information_panel_update_appearance as that code segfaults (at least with GTK 3.21) on dragging a background to the info panel.
We now have a demo for background dragging in GTK3: A background can be dragged to the information sidebar and will be displayed. Won't be saved and won't appear in other Cajs navigation windows, something in the code that segfaulted no doubt needs to be fixed for that but that's for later. At least this widget finally works. It will follow any theme I have and no longer fails to update to BlackMATE or my own theme.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
caja-zoom-control.c: label_style_set_callback to GtkStyleContext in GTK3 builds
|
|
caja-places-sidebar.c: Port caja_places_sidebar_style_set to GtkStyleContext from GtkStyle in GTK3 builds
|
|
caja-pathbar.c: GtkStyleContext is already used to style the pathbar, so removed GtkStyle variables and unneeded caja_path_bar_style_set function
|
|
Port one variable in style_set_handler to GtkStyleContext in GTK3 builds
|
|
caja-information-panel.c: Port caja_information_panel_style_set to GtkStyleContext in GTK3 builds
|
|
caja-history-sidebar.c: port caja_history_sidebar_style_set GtkStyleContext in GTK3 builds
|
|
In GTK 3.21, the use of GtkStyle in function style_set in caja-sidebar-title.c results in a segfault if the sidebar is showing, even though it is used only when the "information" sidebar is selected. GtkStyle also appears in update_title_font in the same file.
The second function resizes the bold headline label font in the information sidebar when either the length of the text or the width of the sidebar changes. Port it to GtkStyleContext and keep it.
The first function (style_set) does two things: It invokes the second function when the style is set up, so port its second input variable (which seems to receive only NULL anyway) to GtkStyleContext. The rest of the function is supposed to set the font for the "more information" label, but mostly seems to block updating that font with the system font and cause the size of the font to be different between GTK 3.20 or earlier and GTK 3.21. Disable that portion entirely in GTK3 builds, as that way the font is consistant across GTK3 versions(an appropriate size in all cases tested), updates with changes in the system font, and cannot segfault in GTK 3.21. Porting it to GtkStyleContext has been tested and stops the segfaults but leaves the other two problems mentioned. Disable that portion of style_set in GTK3 and be done with it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adapted from:
https://git.gnome.org/browse/nautilus/commit/?id=7428762ea6601abba086fcc5e57f443b2e2b40b5
fixes https://github.com/mate-desktop/caja/issues/326
|
|
|
|
inspired by:
https://git.gnome.org/browse/nautilus/commit/?id=dad5d12
|
|
The existing style class .caja-desktop does not match every widget
which you see at the screen. Ie. the widget scrolledwindow,
which is above the existing class in hierarchy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the background might be not yet set at this point, and when it will
be set, the label colors will be properly set on a signal anyway.
so let's not do the same work twice.
|
|
that's what was causing random font color changes. the code in
eel-background.c is a complete asynchronous mess, with queued
callbacks sometimes being called in such order that it caused
blocking the background change signal in the situations where
it should never be blocked.
|
|
that is, before 057df2dc1d8ea67b477d696ac6feea8aaf392763
the logic itself is valid, but it was somewhat broken later in a few
attempts to fix the annoying font color bugs. so let's restore it.
|
|
Reset default size of desktop window to -1 in GTK 3.19/20 only. The combination of a non-resizable
window with a default size is what causes the desktop to open wrong size.
based on https://github.com/GNOME/nautilus/commit/cf79068dc70c87e963e217e2e8ae149ee5ed1872
"desktop-window: avoid wrong size"
"gtk+ recently changed and unresizable windows now take into account
the default size set. We set the default size for normal resizable
windows in nautilus."
"However the desktop window is a no resizable window. What happens now
when setting a default size is that that size is used instead of the
widget request size, since window sizing now takes precedence over
widget sizing."
"To fix it, set the default size to -1 to override what the nautilus
window does by default, so we can avoid this misbehaviour."
|
|
upstream did the same years ago:
https://git.gnome.org/browse/nautilus/commit/?id=6cb7a112683a7dd1d22b471391619d901bfec039
|
|
|