| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
We need to be a little more careful when determining the overlap
between the new allocation and the grip area. This was causing
vertical scrollbars in evince to overlap with the grip.
|
|
|
|
|
|
| |
This is safer, since GtkWindow subclasses may override realize
and end up with has_resize_grip == TRUE, but grip_window still
being NULL - as is the case with GtkPlug.
|
|
|
|
| |
Replace with g_object_set_qdata_full usage.
|
|
|
|
| |
This causes problems for links in labels.
|
|
|
|
|
| |
Apparently 2.4 is out, I'm not aware of a reason we shouldn't
allow it.
|
|
|
|
|
|
|
|
| |
We need to position the grip window in size_allocate after all,
otherwise the grip ends up in the wrong place when the window
is realized early.
Also, avoid shadowing a variable.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
to gtk_widget_get_preferred_size().
|
|
|
|
| |
Otherwise key might be printed uninitialized.
|
|
|
|
|
|
| |
This was another case of making sure size-request was called
before other code was doing get_child_requisition(), now caching
is done via the same api so no need for that line.
|
|
|
|
|
|
| |
Old code was probably doing size-request on all children initially,
and then calling get_child_requisition() in other passes, now these
are cached after the first request anyway.
|
|
|
|
| |
request time).
|
| |
|
| |
|
|
|
|
|
|
|
| |
If there are both horizontal and vertical scrollbars, there is
an unused 'corner' into which the resize grip fits. Individual
scrollbars need to be shortened and moved to make room for the
resize grip.
|
|
|
|
|
|
|
|
|
| |
We remove the resize grip from GtkStatusbar, but keep the code
that makes the content avoid the grip, and adapt it to GtkWindow
grips.
The gtk_status_bar_set/get_has_resize_grip() functions and related
properties are removed.
|
|
|
|
| |
This function is going away.
|
|
|
|
|
|
| |
Chain up in the draw() implementation of GtkAssistant to let
GtkWindow draw the resize grip. This avoids black resize grips
in GtkAssistant windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow any window to display a resize grip, in the south-east or
south-west corner, depending on text direction. This is implemented
as a shaped window that gets overlayed on top of whatever content
is there. We add api that allows widgets to avoid the resize grip,
if desired.
The ::has-resize-grip property controls if a window may display
a resize grip. It will only be displayed if the window is resizable
and not maximized.
The size and visual appearance of the resize grip is under theme
control, using the resize-grip-width/height style properties and
the paint_resize_grip style function.
|
|
|
|
|
| |
Turns out that autoconf eats all the m4_define magic before
AC_INIT.
|
|
|
|
| |
Fixes assertion caused by 41d2a4d059d881d8d05419013ae4946a81b308cb
|
| |
|
|
|
|
|
| |
It requires massive changes to build again. I started, but gave
up. More insight is needed.
|
| |
|
|
|
|
| |
Signed-off-by: Javier Jardón <jjardon@gnome.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to it
If you type 'subfolder/' and hit Enter, the file chooser will switch you to
it. But if you type just 'subfolder' without the trailing slash, apps would
receive *that* filename (e.g. file:///foo/bar/subfolder) as the response, and
they would likely print an error that they can't open that file (as it is
a folder). So, we change the file chooser's current folder to that subfolder
in this case.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
|
|
|
|
| |
width and height have been gone for a while...
|
| |
|
| |
|
|
|
|
|
|
| |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=631475
Signed-off-by: Javier Jardón <jjardon@gnome.org>
|
|
|
|
|
| |
Reported by Milan Bouchet-Valat in bug
https://bugzilla.gnome.org/show_bug.cgi?id=631473
|
|
|
|
| |
They are meant to be overwritten by subclasses after all.
|
| |
|
|
|
|
|
|
| |
This reverts commit 99c82af20a5204940ce2cb0f841be0d6f70a2778 and fixes
up things to compile again. Of course, the snapshotting now uses
gtk_widget_draw() instead.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously name_entry_get_parent_info_cb() would fail as it doesn't handle SELECT_FOLDER.
Now we just make that function act the same as for CREATE_FOLDER mode. In either
case, if you type "/blah/nonexistent" and hit Enter, you want a folder
with that name to be created (under the already-existing /blah).
Signed-off-by: Federico Mena Quintero <federico@novell.com>
|
|
|
|
|
|
|
|
| |
The old save_entry_get_info_cb() was misnamed; it is actually used
to see if a file's presumed parent *is* a folder. So we rename
it to name_entry_get_parent_info_cb().
Signed-off-by: Federico Mena Quintero <federico@novell.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enter
file_exists_get_info_cb() used to let some actions fall through to
the code that checks for the file type of the selected file's parent
(e.g. to see if /foo/bar *is* indeed a folder if you type /foo/bar/baz).
However, we need to be more explicit for each file chooser action, as
in SELECT_FOLDER mode typing /foo/foldername and hitting Enter would not
give you an immediate selection, but rather the file chooser would
complain that it couldn't create that directory as it already exists.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
|
| |
|
|
|
|
|
| |
Note the special implementation of this method on GdkOffscreenWindow
that makes sure its current surface is not destroyed.
|
| |
|
|
|
|
|
|
| |
Previous patch f0039aa2a4367df95bda1b6cf3d4a735cafb4eb2
is not correct as it try to fix a bug introduced in commit
3a10216dd01c8d10df235b88c8942b2fda15689b
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=631311
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=630900
|
|
|
|
|
|
|
| |
We subclass GdkWindowImplQuartz into a new GdkRootWindowImplQuartz,
and override the get_context method in order to do this cleanly.
Also made release_context a virtual method, since the root window has
to release its CGContextRef differently compared to normal windows.
|