1. 20 Jan, 2016 1 commit
  2. 12 Nov, 2015 1 commit
    • Olivier Fourdan's avatar
      desktop: undecorate the window before positioning · e257e841
      Olivier Fourdan authored
      Starting with gtk-+3.19, gtk+ tries to compensate for the client-side
      decorations when moving/resizing top level windows.
      
      With this, the Nautilus desktop window is misplaced because at the time
      it's positioned, gtk+ cannot determine it will be undecorated
      eventually, as both the gtk_window_set_decorated() and the type hint
      (_NET_WM_WINDOW_TYPE) are set after gtk_window_move().
      
      To avoid this, invoke the window positioning after
      gtk_window_set_decorated() so that gtk+ is aware that the window is not
      decorated and doesn't apply the offset to compensate for client-side
      decorations.
      
      Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757471
      e257e841
  3. 10 Sep, 2015 1 commit
  4. 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
  5. 24 Aug, 2015 1 commit
  6. 23 Aug, 2015 1 commit
  7. 02 Mar, 2015 1 commit
  8. 24 Jan, 2015 1 commit
    • Carlos Soriano's avatar
      general: rework menus of nautilus · bb884cb6
      Carlos Soriano authored and Carlos Soriano Sánchez's avatar Carlos Soriano Sánchez committed
      Refresh the nautilus menus in the view (context menus) and the menus in
      the toolbar, changin as well in the path the UI of the toolbar to match
      mockups.
      
      In the way, port to GAction and GMenu every action and menu of nautilus
      and some clean ups thanks to this port.
      bb884cb6
  9. 30 Apr, 2014 1 commit
  10. 17 Feb, 2014 1 commit
  11. 15 Feb, 2014 1 commit
  12. 31 Aug, 2013 1 commit
  13. 26 Aug, 2013 1 commit
  14. 20 Feb, 2013 2 commits
  15. 22 Jan, 2013 1 commit
  16. 23 Oct, 2012 1 commit
  17. 28 Aug, 2012 1 commit
    • Cosimo Cecchi's avatar
      window: never sync the View As actions for the desktop · b9f26a57
      Cosimo Cecchi authored
      Since doing so can set a view_id != NAUTILUS_DESKTOP_CANVAS_VIEW_ID to
      its view, which will have bad consequences (i.e. a crash) when
      finalizing the views at application quit.
      This commit fixes it by making sync_view_as_menus an overriddable class
      method.
      b9f26a57
  18. 13 Jul, 2012 2 commits
  19. 11 Jul, 2012 1 commit
  20. 25 May, 2012 1 commit
  21. 26 Apr, 2012 1 commit
  22. 24 Apr, 2012 3 commits
  23. 09 Jan, 2012 2 commits
  24. 01 Dec, 2011 1 commit
  25. 25 Jul, 2011 1 commit
  26. 18 Jun, 2011 1 commit
  27. 06 Apr, 2011 2 commits
  28. 17 Feb, 2011 3 commits
  29. 11 Jan, 2011 1 commit
  30. 02 Dec, 2010 1 commit
  31. 30 Oct, 2010 1 commit
  32. 20 Sep, 2010 1 commit