summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* Updated Spanish translationDaniel Mustieles2020-08-111-499/+513
|
* Update Greek translationEfstathios Iosifidis2020-08-101-20/+18
|
* Update Brazilian Portuguese translationRafael Fontenelle2020-08-101-421/+434
|
* Correct a typo in Overview.mdFelix Yan2020-08-091-1/+1
|
* Update Catalan translationJordi Mas2020-08-091-408/+414
|
* Update British English translationBruce Cowan2020-08-091-953/+992
|
* Update Turkish translationEmin Tufan Çetin2020-08-091-84/+137
|
* Update Ukrainian translationYuri Chornoivan2020-08-081-36/+19
|
* properties-window: Stop translating placeholdersPiotr Drąg2020-08-081-4/+4
|
* properties-window: Set buttons in change permissions dialog as translatablePiotr Drąg2020-08-081-2/+4
| | | | Also add mnemonics.
* Update Ukrainian translationYuri Chornoivan2020-08-081-459/+575
|
* Update Greek translationEfstathios Iosifidis2020-08-081-85/+146
|
* Update POTFILES.inPiotr Drąg2020-08-081-0/+2
|
* Update German translationChristian Kirbach2020-08-081-735/+759
|
* Update Greek translationEfstathios Iosifidis2020-08-071-418/+371
|
* Update Turkish translationEmin Tufan Çetin2020-08-071-409/+362
|
* Release version 3.37.903.37.90Ondrej Holy2020-08-073-2/+10
|
* properties-window: Center permissions horizontallyAntónio Fernandes2020-08-052-0/+4
| | | | | | | | | If the window grows larger, the permissions look pushed to the left. Same problem with the "Change permissions..." dialog, which is wider by default due to a long window title. So, in both cases, let's center the contents.
* properties-window: Reduce Open With natural widthAntónio Fernandes2020-08-051-1/+1
| | | | | | | | | | | The Open With tab makes the whole dialog wider than it needs to be, making other labs look stretched. This is because the label has a very high natural width, in spite of wrapping, which is attributable to the max-width-chars property. So, halve the value of that propert to give the Properties window a more fitting natural width.
* properties-window: Follow HIG layout adviceApoorv Sachan2020-08-052-108/+84
| | | | | | | | | | | | | | The GNOME Human Interface Guidelines include spacing rules for widgets laid out in a grid, and spacing from window edges: https://developer.gnome.org/hig/stable/visual-layout.html.en For vertical spacing between groups of controls, we have been using empty label widgets. This doesn't give us the control over the heigh that we need, so shall use margins instead. In case of the Basic page, due to the conditionality of the first widget in a group, instead of propper margins we use an empty box with a set heigh as a spacer. Also, prefer the GtkBox:spacing property over the padding child prop.
* properties-window: Reposition icon above basic gridApoorv Sachan2020-08-052-3/+5
| | | | | | | | With the title labels aligned to the right, the icon widget is isolated at the left side, pushed to the edge and disconnected. Center the icon horizontally, at the top of the page, for better visual balance. Also, make it slightly larger, using standard icon size.
* properties-window: Set style with better text contrastApoorv Sachan2020-08-052-0/+6
| | | | | | the outermost GtkBox is set to use 'view' style class for a better contrast between background and the dimmed title lables.
* properties-window: HIG Complaince stylingApoorv Sachan2020-08-053-59/+161
| | | | | | * All the title labels are right Aligned * All labels appear in a lighter shade - dim-label styling * ':' symbol has been removed which succeeds the title labels
* properties-window: Align Contents title lable propperlyApoorv Sachan2020-08-052-20/+1
| | | | | | | | | When the Contents field displays a multi line message the Contents label needs to be aligned to the first line. Traditional implementation achieved this by conditionally appending a newline character, however now that valign property could be used to achieve the same, by setting it to "Start"
* properties-window: Remove unused struct membersApoorv Sachan2020-08-051-3/+0
|
* properties-window: Stop setting "use_original" dataApoorv Sachan2020-08-051-53/+26
| | | | | now, value_field_update() and value_field_update_internal() are merged into value_filed_update()
* properties-window: Stop setting "inconsistent_string" dataApoorv Sachan2020-08-051-43/+4
| | | | This is always the same for all labels, so there is no point.
* properties-window: Removing dead functionsApoorv Sachan2020-08-051-363/+0
| | | | They lost their UI-building role to GtkBuilder.
* properties-window: Clear list of dangling pointersAntónio Fernandes2020-08-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | The window->change_permission_combos list is populated each time the "Change Permissions of Enclosed Files" button is clicked. This list is cleared when the Properties window is destroyed, but not when the "Change Permissions of Enclosed Files" dialog is. As a result, if the button is clicked again, new combos are prepended to the list but the previous (now-dangling) pointers are still there. If GLib is built without -DG_DISABLE_CAST_CHECKS, then trying to use this dialog a second time to change permissions of enclosed files will result in a crash due to the dangling pointers failing a cast check. But even though production code will not crash this way, leaving dangling pointers in the list is a bad idea. Before this dialog was ported to a GtkBuilder UI definition, this bug was masked by a leak of floating references. To properly manage the lifecycle of this list, let's clear it whenever the dialog is destroyed.
* mime-application-chooser: Remove the whole classApoorv Sachan2020-08-054-549/+0
| | | | | | Until the previous commit, its single user was the Properties window. Now it's unused, so we can remove the its source files completely.
* properties-window: Stop using NautilusMimeApplicationChooser classApoorv Sachan2020-08-052-11/+384
| | | | | | | | | | | | | | | | The template UI definition has the Open With tab empty. This is because its contents come from the NautilusMimeApplicationChooser widget. But a separate abstraction for choosing appications based on MIME types isn't required as GTK provides GtkAppChooser. The other widgets can be neatly tucked away in the UI built using XML templates to achieve the same results, and at the same time allowing the open-with page to be customizable in Glade. Some functions are adapted from mime-application-chooser.c, but modified to remove any dependency on that class.
* properties-window: Add "Open With" tab to templateApoorv Sachan2020-08-052-10/+33
| | | | | | This commit only creates outer container of the Open With tab. Inner widgets are ported in the next commit.
* properties-window: Port "Change Permissions..." dialog to GtkBuilderApoorv Sachan2020-08-053-41/+190
| | | | | | | | | | | | "Change Permissions of Enclosed Files" dialog is now built using XML UI definition. This is present as a seperate .ui file apart from nautilus-properties-window.ui because a .ui file file containing a widget declared as a template cannot have other external widgets to be built independently from the template. This .ui file is not produced or editable usingg Glade as it doesn't recognize "action" type children as found in GtkDialog. This issue is already reported in https://gitlab.gnome.org/GNOME/glade/-/issues/392
* properties-window: Populate remaining grid rows from templateApoorv Sachan2020-08-052-56/+174
| | | | | The dialog the "Change Permissions for Enclosed Files…" button opens is going to be ported in the next commit.
* properties-window: Populate Owner, Group and Others rows from templateApoorv Sachan2020-08-052-78/+503
| | | | | | | | | | | | | | | | | | Combo boxes are empty in the template. Their models and renderers are still handled programatically, because porting them posed many issues: - User lists and groups lists are not staic. - Permissions list stores have a column for permissions enum. While we can use the enum value symbol in C, we would have to use a numeric value in Glade, which is going to be quite obscure and hard to document. - Porting the models to GtkBuilder UI definition isn’t really improving hackability / design-ability much because of how Glade handles it. - The comboBox itself is already defined in the .ui file, so it’s possible to tweak the design even if the comboBoxes look empty It would make things more complicated, so it’s more reasonable to let the code handle this.
* properties-window: Add conditional prompt labels to the templateApoorv Sachan2020-08-052-10/+59
| | | | Also document the code generating label text containing file names.
* properties-window: Add Permissions tab outer containers to templateApoorv Sachan2020-08-052-25/+57
| | | | Internal widgets will be populated from template in the next commits.
* properties-window: Add volume usage grid to templateApoorv Sachan2020-08-052-123/+222
| | | | | | The skeleton, layouting of grid cells, and styling of widgets inside the volume usage widget is done in the template. Only the GtkDrawing areas are drawn using code, in callbacks for ::draw.
* properties-window: Populate all rows in templateApoorv Sachan2020-08-052-142/+537
| | | | Exception: the usage widget continues to be constructed in our own code.
* properties-window: Populate Name row from templateApoorv Sachan2020-08-052-83/+73
| | | | | | | | | | | We have been creating either an entry or a label for the name field, depending on whether we were able to edit the name or not. In GtkBuilder UI definitions we cannot do this anymore, as we have to define and build both the entry and the label. So, in order to only show the one we want on each situation, we are introducing a GtkStack to contain both.
* properties-window: Define icon widget in templateApoorv Sachan2020-08-052-40/+57
| | | | | | | | | | | The GtkImage that displays the window icon may or may not be contained by a GtkButton, depending on whether we were able to set a custom icon. In GtkBuilder UI definitions we cannot do this anymore, as we have to set a parent for the image widget from the start. So, define both a simple image and a button with an image, and pack them in a GtkStack to only show the button when appropriate.
* properties-window: Add Basic tab containers to templateApoorv Sachan2020-08-052-18/+92
| | | | | | | | | This commit obtains the outer containers of the Basic page from the widget template UI definition. A new GtkBox to pack the icon widget is included. The inner widgets are ported to the UI definition in the next commits.
* properties-window: Add composite widget templateApoorv Sachan2020-08-053-19/+64
| | | | | | | | | For now, only the outermost containers, GtkWindow down to GtkNotebook, have been defined in the GtkBuilder UI file. The Basic, Permissions, and Open With tabs, along with their content, are still built and inserted programaically. They are going to be ported accross the next series commits.
* properties-window: Restore close on press 'Esc' functionalityApoorv Sachan2020-08-051-0/+7
| | | | | | | | | | NautilusPropertiesWindow usec to be a GtkDialog subclass, inheriting the "close" signal, which was leveraged to implement close on Esc. However as GtkWindow doesn't feature a "close" signal natively, and NautilusPropertiesWindow now subclasses GtkWindow, it needs to be seperately defined and attached to a signal handler to restore the functionality.
* properties-window: Inherit from GtkWindow instead of GtkDialogApoorv Sachan2020-08-052-29/+8
| | | | | | | | | | | | | | The properties window has been subclassing GtkDialog since long ago. GtkDialog features an action area where, historically, the properties window added Help and Close action buttons. These action were dropped when a headerbar was adopted.[1] Moreover, we want to port the Properties window to a GtkBuilder UI definition, which GtkDialog makes harder to achive. Subclassing GtkWindow fits this use case much better. [1] d8a8ab3b66a0a4849e2f9cd17e96f86f85541dee
* progress-info: Prevent crashes when job is cancelledOndrej Holy2020-08-041-36/+10
| | | | | | | | | | | | In order to prevent deadlock when cancelling operations, new thread were added by commit 2db9a295. However, this introduce various races. One of them has been fixed by commit 45c7c967. However, I am convinced that there is still a race when finalizing. One way to fix it is the usage of g_thread_join. But I think that it would be better to avoid the deadlock another way. Let's instead remove the problematic thread and call g_cancellable_cancel without the lock held. Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/124
* Update Persian translationDanial Behzadi2020-07-291-221/+221
|
* triage-policies: Drop @mentionsAntónio Fernandes2020-07-251-2/+0
| | | I get an email anyway, and Carlos is not working on nautilus nowadays.
* Update Brazilian Portuguese translationRafael Fontenelle2020-07-241-738/+772
|
* Update Catalan translationJordi Mas2020-07-231-5/+5
|
View Lorry Controller Status