Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
The extra condition here that caused the current child to
not redraw during reordering was introduced in f383e1f1
during the port to ::draw, but was not explained in the
commit message, and removing it has no obvious negative
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=730767
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
Add a has-tab-gap style property to GtkNotebook so that we can
disable drawing the gap between tabs and the page in the Adwaita
theme without breaking existing themes.
https://bugzilla.gnome.org/show_bug.cgi?id=707920
And use the "header" style class to do that.
This allows themes to set e.g. the background of the tab header
differently.
Themes will need slight adjustment to make things appear
as before.
https://bugzilla.gnome.org/show_bug.cgi?id=643914
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
This avoids an evil trap when doing MAX (..., ... - 2 * border_width)
and the expression on the right gets promoted to unsigned, instead
of going negative as you would expect.
https://bugzilla.gnome.org/show_bug.cgi?id=699633
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
The GtkNotebook drag-motion event handler may install a timeout when
hovering over a tab, in order to switch to it.
On the other hand it's desirable for applications to use the empty tab
area as a drop target, so the drag-motion handler returns FALSE
(also in case it installs the switch tab timeout), as explained in
https://bugzilla.gnome.org/show_bug.cgi?id=350665.
Unfortunately, applications can use the tab label widget (or a child
of it) as a different drop target area, and install their own
drag-motion handler there.
In this scenario, the timeout will still be installed by GtkNotebook's
handler, but since it returns FALSE, it will never get the matching
drag-leave event, causing it to trigger also when the mouse pointer
moved elsewhere before it expired.
Fix this by returning TRUE from drag-motion when the event is over a
tab. Note that this makes automatic tab switching not work anymore when
drag and drop is handled in the tab label widget; applications are
expected to also handle tab switching if desired in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=684415
When the tab label gets removed from the notebook on widget
desctruction, we should still unconditionally unparent it from the
notebook, since failing to do so will keep a stray reference alive.
In case applications rely on the tab label being destroyed to release
other references (e.g. because the tab label is a custom object, or
another object's lifecycle is tied to it using g_object_set_data_full()),
this will also possibly cause other references to get leaked.
In Nautilus, the result was we were failing to release the reference to
a NautilusWindowSlot, and other parts of the application relied
on it being destroyed at a specific time instead, causing the
application to crash when closing a window.
This is a regression from commit
325cf071d1.
This commit restores the previous unparenting behavior in case we're not
in a DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=680349
When using Shift-Tab to move the focus out of page content onto
the tab label, we end up in a situation where both Tab and Shift-Tab
move focus back into the page, which is not really what is expected
when the notebook is part of a dialog.
Instead, arrange things so that using Shift-Tab with focus on a
tab label moves the focus out of the notebook.
http://bugzilla.gnome.org/show_bug.cgi?id=669986
It turns out that we can end up removing a notebook child while
the tab is still 'detached'. Child removal causes
gtk_notebook_remove_tab_label() to be called on the tab label,
but that function did not deal with the eventuality that the tab
label may be a child of the dnd window.
http://bugzilla.gnome.org/show_bug.cgi?id=677943
This is probably going to be replaced by something different soon, but
in the meantime, fix this annoying bug, visible e.g. in widget-factory
for left/right tab examples.
When moving a page around, all children changing their position
need to be notified.
There are still other places where proper notification is missing
(drag 'n drop, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=669116
When doing DnD between windows the tab label is set as the child of
the DnD info window. If this is happening the remove method of
GtkNotebook should not unparent the tab label, since it's been already
unparented, belongs to the DnD window and will be properly destroyed
when the DnD is over.
https://bugzilla.gnome.org/show_bug.cgi?id=639875
Instead of taking the first page and trying to adjust the rect with
random padding values, take the current page, as it's always guaranteed
to be at least as tall as inactive tabs.
This fixes some annoying 1px drawing artifacts while switching tabs when
the theme disables notebook padding.
https://bugzilla.gnome.org/show_bug.cgi?id=664494
When the active page is switched, it's important
gtk_notebook_pages_allocate() is called after the bulk of
gtk_notebook_real_switch_page() is run, as the former allocates a
different space according to the currently active tab, which is set by
the latter.
gtk_notebook_pages_allocate() already calls gtk_notebook_redraw_tabs()
when the allocation changes, so just move its call down to
gtk_notebook_real_switch_page() to fix the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=662629
When we use the style context to get information for the tab region,
also add a style class to indicate its position, so that the relevant
information is pulled off from the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=659777
The setter for this was deprecated in 2.x and removed in 3.0.
I don't see any reason why we should hardcode 2px for this value;
instead, deprecated the getter and make it always return zero, and stop
using the variables internally.
https://bugzilla.gnome.org/show_bug.cgi?id=659777
The code before was basically adding and removing the same padding value
in two different places during the allocation cycle.
Instead, what we want to do is to offset the inactive tab allocation by
the difference with the active tab padding, to ensure the tab content is
always drawn centered and in the right position.
https://bugzilla.gnome.org/show_bug.cgi?id=659777
We want to enable the use of different padding values between active and
inactive tabs, so that the two are completely separated (but limited by
the active tab size).
This way themes can decide how bigger the active tab is drawn compared
to the normal one just specifying a different padding value from the
CSS, like this:
.notebook tab {
padding: 2;
}
.notebook tab:active {
padding: 4;
}
As a first step, fetch the padding values with the right state flags
from GtkStyleContext.
https://bugzilla.gnome.org/show_bug.cgi?id=659777
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Include the child widget path in the returned path now. This allows
customizing the path of the current widgets - like adding flags to child
widgets (and maybe siblings in the future).
