Now we reparent the browse_path_bar_hbox to that spot in Save mode,
or to be above the file lists in Open mode. The pathbar makes for a very
clear indication of the location to save in.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
And with this we get rid of the craziness of having a separate filter model
for the combobox's model.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This effectively makes the file chooser always be in 'expanded' mode.
Later, we'll move the pathbar to the 'Save in folder:' line.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This extracts the parent folders from the items in the recently-used
list. We'll use it in the file chooser to present a list of
recently-used folders.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The table was incomplete and out of date. Instead, just
put a list of links in that place, and move all the extra
documentation to the macros. Bug 653785
When we build the sibling path for the order, we do not skip hidden
children (since, quoting the comment, "we cannot reliably detect changes
in widget visibility"). So we need to invalidate the order when hidden
children are reordered and removed.
https://bugzilla.gnome.org/show_bug.cgi?id=652769
This time I realized that I needed to set autocrlf=false on my Windows side
... ugh...
This is one of those files that must have CRLF line endings to work
correctly :|
-Reinstate build/win32/vs10/gtk+.sln with the correct EOL (DOS/Windows), so
that it will be correctly recognized by Windows instead of having the
annoying "Unrecognized Visual Studio Version".
-Update property sheets to reflect on new headers added
-Change the demo program to be gtk3-demo.exe, to be consistent with the
names on other platforms, and updated/renamed related project/solution
files, and added overlay.c to the list of demo sources.
Removing the window from the window list before setting the
application to %NULL avoids gtk_application_remove_window() triggering
another call to gtk_application_window_removed(), which would release
the application a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=653053
As Cairo and Cairo-GObject are often built as two seperate DLLs/modules,
set the property sheets to link to both libraries, instead of using the
previous approach where a monolithic Cairo DLL which contains GObject
support is used.
-Remove unneeded tags from projects
-Seperate intermediate directories for projects to avoid rebuilding/
linking on every rebuild and MSBuild errors (et al.) for not being
able to write into build log files as they are in use.
