If no file was originally selected in the GtkFileChooserButton, then its
internal dialog is brought up and cancelled, then we need to restore the
selection back to none. GtkFileChooser, though, doesn't like to
select a NULL file, so call _unselect_all() in that condition.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The button's underlying file chooser dialog should not be used to store the file selection
while the dialog is unmapped. Instead, the file chooser button now stores the
selection itself.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to fetch a possibly multiple selection from the GtkFileChooserDialog, and then
pick just the first item from the selection list. But since GtkFileChooserButton
operates in single-selection mode only, it can simply use gtk_file_chooser_get_file()
instead.
Also, the right way to reset the selection for GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
is with gtk_file_chooser_select_file(), not with _set_current_folder_file().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The file chooser is asynchronous, so doing 'select_file (old_file)' and subsequently querying
the file for updating the labels is not going to work. However, the underlying file chooser
will emit 'selection-changed' as appropriate when it finishes restoring the old file. So,
we only need to update the labels when the file chooser dialog is confirmed, not cancelled.
This code came from a home-grown testing mechanism, which didn't aggregate tests
into a test suite; it just ran them one by one. Here we move some of that machinery
to GTestDataFunc for more flexibility in running tests.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
With the binutils-gold linker the '--no-copy-dt-needed-entries' flag is
active by default and using any symbol from indirectly loaded libraries
will result in undefined reference errors.
https://bugzilla.gnome.org/show_bug.cgi?id=692810
gtk_menu_shell_insert() is a virtual function that was being directly
invoked from the class vtable.
Turn it into a proper signal and emit it in the usual way.
See https://bugzilla.gnome.org/show_bug.cgi?id=656565.
This is a backport of Ryan Lortie's commit
05aeaeef9e from the GTK+ 3 branch.
Normally, the xthickness in the style maps to the space on the sides of
the widget, to accommodate for its border - GtkEntry's text area
background width is calculated as (allocation->width - 2 * xthickness),
and the border is rendered in that area.
GtkSpinButton has an additional panel for the buttons though, which will
render the right-side (left-side for RTL) border itself, taking
xthickness into account. This results in the xthickness for that side
being applied twice, both to the spinbutton panel and to the entry's
text area.
Visually, a slice with no painted background can be seen in spinbuttons
on the right side (left side when RTL) of the text area, where the
border would be rendered by the entry, which looks bad.
This patch makes GtkSpinButton render the same background of the entry
in that slice, to compensate for the xthickness being allocated to the
button panel instead.
https://bugzilla.gnome.org/show_bug.cgi?id=683511
When state-hint is TRUE, GTK_STATE_ACTIVE was used to paint the entry
background and frame, since commit
207f3f8685.
Given that everywhere else in GTK2 - including GtkEntry itself in
draw_text_with_color() - GTK_STATE_ACTIVE is used for non-toggleable
widgets to indicate selected but not focused text, this leads to the
entry painting itself with the wrong background color when focused.
This is unsolvable from the theme, as changing the ACTIVE background
color to be the same as NORMAL would give a wrong background to selected
but not focused text as per above.
This patch avoids using GTK_STATE_ACTIVE to paint GtkEntry's background,
changing the code so that the widget state is always used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=692554
The old code to load the last_folder_uri state from the settings was not actually
ensuring that the settings were read from disk. The result was this:
1. user chooses a folder in SELECT_FOLDER mode
2. user dismisses the file chooser dialog inside a GtkFileChooserButton
3. The dialog unmaps itself and saves the last_folder_uri with the user's selection
4. The file chooser button gets queried for the selection
5. GtkFileChooserDefault sees that it is unmapped, and falls back to the last_folder_uri
6. But since that key is not ensured as read by the temporary instance of GtkFileChooserSettings,
it returns nothing.
7. The file chooser falls back to returning the user's home directory.
However, *we don't use the last_folder_uri* anymore, for anything! So, removed
that code and now everything falls back to ->current_folder correctly. This
is the correct selection value for SELECT_FOLDER mode anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=674556
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Reset state of CUPS requests correctly during authentization and
check CUPS requests for errors.
Don't initialize variables holding password and username with empty
string (#664640).
Need to check targets and get_func in each loop iteration because
calling get_func the fist time might do whatever to the clipboard.
Re-fixes bug #626499. Also free the target table after we're done.
Replace long obsolete AM_CONFIG_HEADER with proper AC_CONFIG_HEADERS.
automake-1.13 errors out upon seeing former.
Similarly remove AM_PROG_CC_STDC. It's proper replacement, AC_PROG_CC,
is already present.
Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
...so that we will include the correct gdkconfig.h, which would be
in $(srcroot)\gdk\ during the Visual C++ build.
Also prepare support for Visual Studio 2012 in this project, so it would
be easy to use a script to copy and replace the necessary items in the
Visual Studio 2010 project set to make it a Visual Studio 2012 set.
We must not release the GtkClipboardOwner in pasteboardChangedOwner
becaue we don't own a reference to ourselves (NSPasteboard does).
Instead, release the owner right after setting it, transferring
ownership to NSPasteboard
Also, fix repeated setting of the same owner by keeping the
owner around in GtkCLipboard, and re-use it if "user_data"
doesn't change. To avoid clipboard_unset()ting our own contents
in the process, add an ugly "setting_same_owner" boolean to
GtkClipboardOwner, set it during re-setting the same owner,
and avoid calling clipboard_unset() from pasteboardChangedOwner
if it's TRUE.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2010 project file to build libwimp as a
standalone module/DLL, and the property sheets, .sln file and
gtk.vcxprojin/gtk.vcxproj.filtersin/install.vcxproj are updated
accordingly so that the needed stuff get built properly and go
to the proper places for the Windows Themes to work correctly
with the Visual C++ builds.
Thanks to nus for pointing this out.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2008 project file to build libwimp as a standalone
module/DLL, and the property sheets, .sln file and gtk.vcprojin are updated
accordingly so that the needed stuff get built properly and go to the
proper places for the Windows Themes to work correctly with the Visual C++
builds.
Thanks to nus for pointing this out. Visual C++ 2010 projects files will
be updated in the next 1-2 days.
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
Per the gtk-devel meeting on 2012/11/29, we'll not have a UI in the file chooser dialog
to select between those modes. Instead, we'll show that key in gtweaktool.
This reverts commit 7860500bc6.
