Remove the unused, initial-text logic from the location entry
Years ago, when the location entry only appeared in a popup window, it used to appear
populated with the current folder's path. We had some logic to do this, but since now
the location entry appears in the main dialog, we can do away with that old code.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Centralize changing the operation mode in operation_mode_set()
This will be the central function to switch operation modes: stop searches or the recent-files
process; switch widgets, etc.
We factor out the common code from recent_switch_to_browse_mode() and search_switch_to_browse_mode(),
and remove those functions. All the code that switched modes by hand now calls
the central operation_mode_set().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Save selection to recent-files in the asynchronous Save cases
Various paths in SAVE or CREATE_FOLDER return from ::should_respond() but
leave an asynchronous process running. This process checks some things
in the user's selection, for example, 'does the file exist, and if so
do we need to bring up an overwrite-confirmation dialog?'. When these
async processes complete *and* it is indeed time for the dialog to
be terminated (via the response-requested signal), we also need to
save the selection to the recently-used list - as ::should_respond() does
by itself in the cases when it can request a response immediately.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Log to recent-files when confirming the file chooser
To make life easier for users, when apps don't properly update the recently-used list
after choosing a file, we now do that directly from the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Update the docs with the policies for Save dialogs
Basically, don't ever set the current folder, and only use
gtk_file_chooser_set_filename() for 'File/Save As'. This is so
that the file chooser will be able to present its recently-used
lists as appropriate, giving the user good suggestions by default.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
No need to highlight the file's basename when setting the base folder
None of the cases where _gtk_file_chooser_entry_set_base_folder() appear to require
the entry highlighting the file's basename. Doing the highlighting actually makes
things look weird in Save/Recent mode if you
1. type a filename
2. click on a recent-folder,
as right after (2) your filename would get its basename highlighted for
no apparent reason.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to be that every part of the file chooser's code would show/hide the widgets
near the pathbar as needed. Now we have two central functions:
path_bar_update()
path_bar_set_mode()
These take care of all the widget shuffling; setting the visibility of the
pathbar, info bar, and Create Folder button as appropriate; setting the contents
of the info bar, etc. - based on the current operation_mode and action.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We will centralize the place where all the pathbar-related widgets are created:
the location button, the pathbar itself, the Create Folder button, and in
subsequent commits, the info bar as well. We will deal with the pathbar/infobar
as a unit, instead of swapping them in and out in an ad-hoc fashion.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Return the recent-folder plus filename in Save mode from get_files()
Since the GtkFileChooserEntry already gets the recent-folder set upon it when a recent-folder
is selected, it already can give us the correct fully-formed path.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Allow resolving absolute paths even if there is no base_folder
This lets us do proper completion in GtkFileChooserEntry even when no base folder
has been set. Completion for relative paths won't work, as usual, as expected.
Actually highlight the 'recently used' and 'search' items in the shortcuts bar
They weren't being selected in the shortcuts bar when those modes were
activated programmatically, instead of through the user selecting
them from the user interface.
In RELOAD_EMPTY mode, when no folder has been selected by the calling app, we now
start showing the recently-used list. The rationale is as follows:
- In Open mode, the user is likely to pick a file he has used recently.
- In Save mode, the user is likely to want a destination folder which
he has used recently.
For the Save case, where we want to present the user with recent folders instead
of recent files, we will make the recent-list do so in subsequent commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Put the pathbar in the 'Save in folder:' row in Save mode
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>
Utility function to extract folders from the recently-used list
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>
Cosimo Cecchi [Thu, 30 Jun 2011 20:19:57 +0000 (16:19 -0400)]
box: follow children visibility when building the sibling path
This fixes nth-child not working for widgets which were not
visible before being added to the box, but it's also a better fix
for https://bugzilla.gnome.org/show_bug.cgi?id=652769
Matthias Clasen [Thu, 30 Jun 2011 23:18:26 +0000 (19:18 -0400)]
Fix up docs for predefined style classes.
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
Vincent Untz [Tue, 28 Jun 2011 09:47:37 +0000 (11:47 +0200)]
gtkbox: Invalidate order on changes, even if the child is not visible
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.
Make GtkBuilder do not delay construct properties that can be resolved
(so construct is respected when possible) and skip construct only props that
can not.
Chun-wei Fan [Fri, 24 Jun 2011 04:48:22 +0000 (12:48 +0800)]
Update VS project files
-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.
Claudio Saavedra [Mon, 20 Jun 2011 21:29:45 +0000 (00:29 +0300)]
Avoid GApplication being released twice on gtk_application_remove_window() calls
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.
Chun-wei Fan [Mon, 20 Jun 2011 09:05:00 +0000 (17:05 +0800)]
Update VS property sheets
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.
Chun-wei Fan [Mon, 20 Jun 2011 04:19:54 +0000 (12:19 +0800)]
Refine Visual C++ 2010 projects
-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.
Benjamin Otte [Wed, 15 Jun 2011 20:50:59 +0000 (22:50 +0200)]
toolbar: Better fix for animations
It turns out there's more places where the toolbar item size is used as
the margin box instead of the content box. Because of that, store the
margin box when allocating and use it whenever calls
toolbar_content_get_allocation() instead of calling
gtk_widget_get_allocation().
Benjamin Otte [Wed, 15 Jun 2011 17:59:45 +0000 (19:59 +0200)]
toolbar: Handle the fact that size_allocate() != get_allocation()
size_allocate() allocates the available space for the margin box,
get_allocation() returns the actual space of the content box and those
can be different. And then animations never stop.
If that makes you go "huh?", you might want to read
http://www.w3.org/TR/CSS21/box.html
and the docs for gtk_widget_compute_align().
Cosimo Cecchi [Wed, 15 Jun 2011 05:07:11 +0000 (01:07 -0400)]
themingengine: shrink the background size to the padding-box
This fixes a regression introduced by this commit [1] that causes
background to draw beyond the padding-box, which breaks rounded corners,
(in addition to not being compliant with what CSS does by default).
projects / ~andy / gtk / log