1. 18 May, 2018 2 commits
    • Carlos Soriano's avatar
      general: Revert to allow running binaries and scripts · ce73de0c
      Carlos Soriano authored
      Recently we removed the ability to launch binaries and scripts in
      commit 3a22ed5b.
      
      A few cases appeared that we need to support, specially for enterprise
      and content creators. Specifically, cases similar to #434
      
      This also shows that is hard to predict cases like these, as some
      complex setups might be needed for specific workflows.
      
      This commits allow to run binaries and scripts as before, and further
      investigation in these cases need to be done if we ever want to tweak
      the workflow of running binaries.
      
      More discussion about improving binaries/script handling is being
      proposed and discussed in #443
      ce73de0c
    • Ernestas Kulik's avatar
      general: Clean up headers and their inclusions · e686c297
      Ernestas Kulik authored
      This commit removes redundant header inclusions and tries to optimize
      headers by using forward declarations of types in headers. Such
      optimization should generally make builds speedier in that changes in
      certain headers will not cause unrelated sources to be rebuilt.
      e686c297
  2. 09 May, 2018 1 commit
    • Carlos Soriano Sánchez's avatar
      general: Don't allow launching binaries or programs in general · 3a22ed5b
      Carlos Soriano Sánchez authored
      For long we used to support that since the desktop was part of Nautilus.
      Also, back then we didn't have a Software app where you are expected to
      installs apps. Back then it was common for apps to be delivered in
      a tarball, nowadays that's out of question.
      
      Now that the desktop is long gone, launching binaries and desktop files
      from within Nautilus is not as useful. Not only that, but we are moving
      towards a more sandboxed system, and we should use the standard and
      system wide support for launching apps based on users choices.
      
      We also are not able to be secure enough to handle this, as we saw in
      the past we allowed untrusted binaries to be launched, and therefore
      we had a CVE (CVE-2017-14604) for Nautilus. We are not being audited
      (afaik) and we are not in a position that we can let this issues slip.
      
      With that altogether, this prevents launching binaries or programs from
      Nautilus.
      
      Closes: #184
      3a22ed5b
  3. 03 May, 2018 1 commit
  4. 23 Nov, 2016 1 commit
    • Carlos Soriano Sánchez's avatar
      view: make icon getter static · 88cee392
      Carlos Soriano Sánchez authored
      We were relying on the current view to return the icon to put in the
      toolbar, however that requires a view instance and also we cannot
      control really what icon we want to show in which circumstances.
      
      We want more control about that, so we need a single entry point where
      we can get the icon to show depending on the known view types we
      have.
      
      So this patch converts the view property to a static method.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=771075
      88cee392
  5. 29 Aug, 2016 1 commit
  6. 23 Jun, 2016 2 commits
    • Neil Herald's avatar
      toolbar: move undo/redo toolbar menu code into toolbar · a312f565
      Neil Herald authored
      Due to the toolbar menu reorganisation work, the code to create and
      manage the undo/redo items on the menu ended up in files-view.c. This
      isn't the correct place as they don't have much to do with the files
      view. Some refactoring was needed before the code for these items could
      be moved back into the toolbar, which has now been done in a previous
      commit.
      
      This commit moves the undo/redo creation and management code into the
      toolbar.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764632
      a312f565
    • Neil Herald's avatar
      view: allow view to have more control over the toolbar menu · 35f10147
      Neil Herald authored
      Currently we have this menu structure:
      
      ------------------------------
      1. New Folder/New Tab/Bookmark
      ------------------------------
      2. Zoom controls
      ------------------------------
      3. Undo/Redo
      ------------------------------
      4. Sort options
      ------------------------------
      5. Other view related controls
      ------------------------------
      
      The view creates 2-5, contained in a single GtkWidget - which is then
      passed to the toolbar via the enclosing window slot. The problem is that
      3 shouldn't be created or managed by the view as the controls in that
      section of the menu are not related to the view. We'd like to move this
      responsibility back to the toolbar, but that would mean the view must
      pass multiple menu sections back to the toolbar (as 3 is in the middle
      of the other view controls).
      
      This change allows the view to pass multiple sections back to the
      toolbar, using the new NautilusToolbarMenuSections structure. The files
      view now passes 2 as a separate section to 3-5 (3 will be moved out of
      the view in a future commit).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764632
      35f10147
  7. 22 Jun, 2016 1 commit
    • Neil Herald's avatar
      toolbar: change ownership of menu popover to the toolbar · 83ca8859
      Neil Herald authored
      Prior changes to merge the view and action menus essentially moved the
      action menu items into the view menu. This was the path of least
      resistance; the view has a lot of hooks on items in the view menu,
      whereas the there are very few hooks on items in the action menu,
      meaning the latter could be moved more easily.
      
      However, previously the view menu was disabled for Other Locations and
      the action menu wasn't. So the side effect of the changes is the
      remaining menu is now disabled completely on Other Locations. There are
      a couple of items that could be shown for Other Locations (e.g. New
      Tab), so we still want to show a menu, but this involves some
      refactoring so has been deferred until now.
      
      This commit is the first part of the refactoring; the files view owns
      the menu popover, meaning that the Other Locations view doesn't have
      access to it. This commit moves the ownership of the menu popover to the
      toolbar. Future commits will move the common items into the popover so
      all views will show them.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764632
      83ca8859
  8. 22 Apr, 2016 1 commit
  9. 30 Mar, 2016 1 commit
  10. 29 Mar, 2016 1 commit
    • Razvan Chitu's avatar
      do not switch focus to new tabs · 9028e332
      Razvan Chitu authored
      In Nautilus, when a location is opened in a new tab, the new tab gets
      automatically focused. This behavior is not consistent with other tab-based
      applications, such as browsers - Epiphany, Firefox, Chromium to name a few. It
      is also a regression, since this behavior was not present in 3.14. In order to
      fix this, set a flag so the new tab is not made active.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=764035
      9028e332
  11. 09 Mar, 2016 1 commit
    • Carlos Soriano Sánchez's avatar
      placesview: auto generate code · 0fec6f28
      Carlos Soriano Sánchez authored
      We have been manually copying the code inside nautilus since we
      introduced the places view.
      
      It has been a pain to maintain, mostly because we needed to remove the
      bits that only work inside gtk+ and instead either remove them or make
      a substitution. But that was doable.
      
      However, it reached a new level when we realized that we use the file
      chooser inside nautilus, for the "move to" and "copy to" actions, which
      create makes symbols clash. So we needed to rename all the symbols in
      those files.
      
      Instead of making it manually, create a shell script that fetches gtk+
      repository and make the appropriate substitutions, deletions and what
      not.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=760307
      0fec6f28
  12. 24 Feb, 2016 1 commit
    • Carlos Soriano Sánchez's avatar
      placesview: avoid symbol conflicts · 82a27ab9
      Carlos Soriano Sánchez authored
      Copy pasting the code from gtk+ has the downside that symbol conflicts
      occur when the file chooser is shown, for example, when performing a
      move to action.
      
      Only way to dealing with it is either make this public on gtk+ or
      renaming the types. We don't want to make it public yet, so the only
      option for now is renaming.
      
      Is a tedious task and I hope it won't be needed in the future.
      For now, rename the types manually.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=760307
      82a27ab9
  13. 11 Dec, 2015 1 commit
  14. 13 Nov, 2015 1 commit
    • Carlos Soriano Sánchez's avatar
      nautilus-places-view: sink the reference on creation · c22b545d
      Carlos Soriano Sánchez authored
      Last patch now makes view reference counting works, however
      NautilusFilesView sink the ref on creation, and NautilusPlacesView
      was not, making NautilusPlacesView holding a reference less than other
      views and making nautilus crash.
      
      Follow what other views do and sink the reference.
      c22b545d
  15. 28 Aug, 2015 1 commit
    • Carlos Soriano Sánchez's avatar
      general: separate handling of windows/slots/views · 28f50cfe
      Carlos Soriano Sánchez authored
      This is another step towards the isolation of the management
      of the direcotories, views, slots and windows.
      The current situation had a few issues:
      - the comunication of changes in the model was done in a
      bidirectional way. So for example, sometimes the view updates
      directly the slot, sometimes directly the window, and sometimes
      the window was listening to changes on the model and updating the slot,
      view, or model itself. Problem with this is, encapsulation is wrong,
      the code paths are confusing, and the public API exposed is big.
      - public API is big, so even if sometimes if convenient to not do the
      same thing twice, having public API that is actually covered by the GLib
      or Gtk API doesn't worth it, if the complexity of the API grows too much.
      In Nautilus case, specifically on the slot, we were allowing all kind of
      convenient API, but it was behaving differently depending on small connotations.
      - management was not encapsulated. So the window was modifyng the model, or
      doing actions that belongs to the slot or the view. The same thing for the slot
      and the view, and similarly for the application and the window. For example,
      we were handling the flag for creating new windows on a specific window,
      instead of relying on the application management. Similar cases for the slot
      and the view.
      - there were multiple code paths for opening a location. This is one of the
      biggest changes on the patch. We were exposing API to open a location in every
      component, and we were using that API from other components above or below the
      hierarchy randomly. So for example the view was using the opening location
      API from the slot, the window, and the application; but with the same pourpose,
      opening a location in the active window.
      - API was not explicit. For example sometimes we wanted to open
      a location in the current active window, but somtimes it was implicit and
      sometimes not, and to be safe we were making it explicit on the caller.
      - we were using mutiple code paths with the same intention. This is related
      to the previous one, the intention in every caller was not clear.
      
      This patch tries to improve the situation, also thinking on the future
      rework of the views and separation of the desktop handling.
      The patch applies the following rules:
      - If the API is provided somehow by nautilus-file or Glib or Gtk, don't
      add new API. Custom API is fine if it is used inside the component itself,
      since the added complexity for tracking code paths is not that important.
      - Use one way communication, from the top level to the innermost component.
      In case that the component needs top level features, ask the most top level.
      A specific example, the view provides opening a new window with a selection.
      Although encapsulation is good, there is not a good way to avoid the dance
      from the model to the view to the slot to the window to the application.
      So instead of that, allow a quick shorcut only communicating to the top most
      level. In this way, the code path is always the same (therefore much easier to
      debug or to change code) and encapsulation is preserved.
      - don't break encapsulation. Only allow management of the component to the component
      itself or its parent. So for example, the slot is the one that manages errors on what
      happens in the slot itself.
      Exception to this is the application, that needs access to all the hierarchy for
      specific situations. For example for updating the dbus locations or to discern
      between a desktop window or a common window.
      - if two way communication is needed, listen changes through properties.
      We have been moving to properties lately, since it clearer and cleaner and
      allow a few features that are useful like listening to its changes withouth
      explicit API for it. This allows to bind properties in a clean way throuh the
      hierarchy and not breaking the encapsulation.
      
      In this patch most of the ground work is done, and some things are remaining
      like moving all the loading of the location to the view instead of the slot.
      Even if it is convenient to have some management on the slot to share between
      the views, some views don't use models at all, or they are not common
      files, like the other-locations, and this breaks the situation. At some point
      what we want for the files-view is having a common model API, that can be on top
      of nautilus-file or in nautilus-file itself.
      
      With this patch, a serie of improvements can be done now, and they will
      come in future patches.
      28f50cfe
  16. 20 Aug, 2015 1 commit
    • Georges Basile Stavracas Neto's avatar
      places-view: implement a view for Other Locations · 404f1492
      Georges Basile Stavracas Neto authored
      GtkFileChooser received a Other Locations view that lists
      persistent devices, as well as networks and the root location
      for the computer's hard drive.
      
      Since Nautilus is a file management tool too, it should keep
      consistency between Gtk+ file chooser, something that doesn't
      happen since it doesn't display Other Locations.
      
      To fix that, add NautilusPlacesView, a NautilusView implementation
      that displays the GtkPlacesView widget. In order to implement that,
      update window-slot to correctly display the places-view whenever
      Other Locations is clicked.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=753871
      404f1492