- Jul 20, 2016
-
-
Carlos Garnacho authored
-
Carlos Garnacho authored
This is an implementation of the pad OSD that's been previously present in gnome-settings-daemon. Since things are moving closer to the compositor, it makes sense to have this implemented as shell UI.
-
Florian Müllner authored
If a sandboxed app requests access to some system resource (camera, microphone, location), the portal frontend needs to ask the user for permission. In GNOME, we want this to be a system modal dialog, so provide an org.freedesktop.impl.portal.access implementation that exposes a generic system modal permission dialog on the bus. https://bugzilla.gnome.org/show_bug.cgi?id=768669
-
Jonas Ådahl authored
There is no longer any guarantee that there'll be one single framebuffer to read pixels from. In order to still read pixels from the stage, use the new clutter_stage_capture API. https://bugzilla.gnome.org/show_bug.cgi?id=768979
-
- Jul 19, 2016
-
-
Marinus Schraal authored
Require at least 3.21.3 for the MRU input source schema. https://bugzilla.gnome.org/show_bug.cgi?id=768956
-
- Jul 18, 2016
-
-
- Jul 12, 2016
-
-
Florian Müllner authored
This will allow us to create a ShellApp from JS code, for instance for .desktop files that aren't known to the AppSystem. https://bugzilla.gnome.org/show_bug.cgi?id=762206
-
Piotr Drąg authored
-
- Jul 08, 2016
-
-
Florian Müllner authored
Instead of querying the client for a list of objects and using e_cal_recur_generate_instances() to get occurrences for each of them, we can use e_cal_client_generate_instances_sync() which combines the functionality of both functions. This doesn't only save us some lines of code (yay!), but also gives us access to the real recurrence ID of an event, so we can get rid of the hack of faking one. https://bugzilla.gnome.org/show_bug.cgi?id=748226
-
Florian Müllner authored
We use the triplet of source ID, UID and recurrence ID to create an ID to unambiguously identify an event, which we use to implement hiding dismissed events from the calendar. However we currently try to fetch the recurrence ID from the objects returned by e_cal_client_get_object_list_sync(), which are always the primary events with no recurrence ID. Instead, we need a recurrence ID associated with each occurrence. https://bugzilla.gnome.org/show_bug.cgi?id=748226
-
Florian Müllner authored
We are already setting the default zone on the client, no need to pass it around. https://bugzilla.gnome.org/show_bug.cgi?id=748226
-
Florian Müllner authored
App will take ownership of the location string when the timezone changes, but not when there was no change - free the memory in that case. https://bugzilla.gnome.org/show_bug.cgi?id=748226
-
Florian Müllner authored
We use the same query string for all sources, so no need to allocate/free it on each loop iteration. https://bugzilla.gnome.org/show_bug.cgi?id=748226
-
Florian Müllner authored
We currently use the :active pseudo class to mark the selected day in the calendar. Whenever the selected date changes, the class is added to the corresponding button and removed from all others. However when the selected date doesn't change (i.e. when clicking the already selected date), the buttons are not updated and the use of the :active class conflicts with StButton's builtin handling of the class - the class is removed on the button up event and the button is deselected. Fix this by simply using a different pseudo class. https://bugzilla.gnome.org/show_bug.cgi?id=746867
-
Florian Müllner authored
The last patch fixed marking days in the calendar where all events are ignored, but it doesn't pick up the change when an event is hidden. Emit an appropriate change notification to fix this issue. https://bugzilla.gnome.org/show_bug.cgi?id=768538
-
Florian Müllner authored
Ignoring events is currently implemented in the message list's event section, which means that the calendar does not consider ignored events when marking days with events. In order to fix this, move the handling of ignored events to the event source, which is shared between both components. https://bugzilla.gnome.org/show_bug.cgi?id=768538
-
- Jul 07, 2016
-
-
Florian Müllner authored
calendar_appointment_new() never returns %NULL, so no need to check for it.
-
- Jul 05, 2016
-
-
Florian Müllner authored
Commit 9b07ce1d broke the code that keeps the OSD window square. Use that opportunity to move away from the hack of setting the min-height style property from code and adjusting the width on allocate, and implement a proper constraint instead. https://bugzilla.gnome.org/show_bug.cgi?id=768317
-
Florian Müllner authored
ClutterActor:width is a floating point property, so it will not be automatically rounded to non-fractional values that properly align to pixels. To fix the resulting blurriness, add explicit rounding. https://bugzilla.gnome.org/show_bug.cgi?id=768317
-
Florian Müllner authored
Commit 9b07ce1d changed the OSD window's level bar to be a regular actor instead of a custom drawn bar. The bar actor's width depends on both the configured level (e.g. 40%) and the available width, however the width is currently only updated when the configured level changes. Fix that by properly considering changes to the parent's width as well. https://bugzilla.gnome.org/show_bug.cgi?id=768317
-
Florian Müllner authored
Commit c39ffa11 moved the signal handling from the controls- to the background-group to enable scrolling on non-primary monitors. However this broke scrolling on reactive overview elements as the workspace switcher, as they're not descendants of the background. To fix, move scroll-event handling to the overview group itself, which is the common ancestor of all overview elements. https://bugzilla.gnome.org/show_bug.cgi?id=768316
-
-
- Jul 01, 2016
-
-
Piotr Drąg authored
-
Bruce Cowan authored
-
- Jun 30, 2016
-
-
Owen W. Taylor authored
When we restart, we need to update the struts for the screen before we enter the main loop, or maximized windows will get resized to the size of the screen without struts, then resized back. A workaround is needed for a Clutter bug that occurs when we get the size of an actor before the first paint of the stage. https://bugzilla.gnome.org/show_bug.cgi?id=761566
-
Owen W. Taylor authored
-
-
-
-
-
- Jun 29, 2016
-
-
The memory which MetaBackground resides is freed automatically, when its wrapper object Background is freed by garbage collection. But because the memory for MetaBackground is huge, changing the background or changing the background mode repeatedly makes a lot of memory to be in use until garbage collection runs. This patch frees the MetaBackground object explicitly when its MetaBackgroundActor is destroyed which is the moment that the memory in the object is not used anymore. https://bugzilla.gnome.org/show_bug.cgi?id=766353 Signed-off-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
-
- Jun 28, 2016
-
-
Rui Matos authored
This makes style changes propagate to our child widget as they should. https://bugzilla.gnome.org/show_bug.cgi?id=739178
-
Rui Matos authored
This isn't a performance critical actor and the NVIDIA driver discards offscreen buffers in some cases which would require us to go through extra hoops to handle here which isn't worth it. https://bugzilla.gnome.org/show_bug.cgi?id=739178
-
Rui Matos authored
The theme machinery uses FBOs in some cases (mainly for shadows) which need to be reloaded if we get a video memory purged error. https://bugzilla.gnome.org/show_bug.cgi?id=739178
-
Rui Matos authored
When running as a wayland compositor, MetaCursorTracker might legitimately not have a displayed cursor because e.g. a client unsets the cursor surface. Note that, under an X session, the assumption that the tracker always has a cursor texture is true because XFixesGetCursorImage() always returns data even if the cursor isn't visible. https://bugzilla.gnome.org/show_bug.cgi?id=767001
-
Rui Matos authored
Otherwise we may end up using freed memory and crashing https://bugzilla.gnome.org/show_bug.cgi?id=767001
-
- Jun 27, 2016
-
-
Florian Müllner authored
It is odd to switch workspaces on the primary monitor when panning on a monitor without workspaces, so reject the gesture on non-primary monitors when workspaces-only-on-primary is disabled. https://bugzilla.gnome.org/show_bug.cgi?id=766883
-
Florian Müllner authored
It is odd to switch workspaces using the scroll wheel when the pointer is on a monitor without workspaces, so only handle scroll events on non-primary monitors when workspaces-only-on-primary is disabled. https://bugzilla.gnome.org/show_bug.cgi?id=766883
-
Florian Müllner authored
We allow activating a workspace by clicking it when we know that the user did not try to select a window and missed (namely: the workspace is empty). However we currently always check for an empty workspace on the primary monitor, which doesn't make sense when the click happened on a different monitor. https://bugzilla.gnome.org/show_bug.cgi?id=766883
-
Florian Müllner authored
Both the Overview::scroll-event and actions added via addAction() are meant to work anywhere in the overview, but for now only work on the primary monitor. Move the handling to the background group that is known to span all outputs to fix. https://bugzilla.gnome.org/show_bug.cgi?id=766883
-