Summary:
Set xkb context and keymap to Ecore_Drm.
In enlightenment (used in wayland with drm backend), keymap is used only one.
So for avoid unnecessary open keymap files, set cached context and keymap.
But for this, enlightenment must compile keymap before init ecore_drm.
So I changed booting sequence also.
Test Plan: Distinguish time between before and after during add a keyboard device.
Reviewers: raster, devilhorns, zmike
Subscribers: cedric, input.hacker, ohduna
Differential Revision: https://phab.enlightenment.org/D3504
I can't find anything in the specs that would imply those shouldn't be
tiled. This may cause placement bugs, but I don't think that'd be the
case, as we ignore application placement when tiling anyway.
@fix
the coordinates passed to this function were never used or tested for
being a valid placement location, resulting in any clients which started
with a given position being moved to a pre-existing smart placement test
case, usually the upper-left or lower-right corners of the screen
fix T1106
in the case where a new client already has coordinates from creation event,
the frame was never adjusted which resulted in the window being positioned
incorrectly
ref T1106
if shown while a hide animation is running, evas will prevent further show
intercept callbacks from being reached, resulting in a permanently hidden
shelf
this shortcuts the (current) hide animation in order to begin showing the object
failing to unpopulate at this time leaves gadcon clients alive until
a time after module shutdown has occurred, resulting in crashes when
gadcon clients destroy themselves and attempt to access module-global
data
ref T2811
Summary:
@fix the display / customisation of KDE5 apps.
KDE5 applications don't understand anything other then gnome or kde
They expect everyone else to set QT_QPA_PLATFORMTHEME to tell them how
to theme there apps otherwise they use a fallback mode which results in
missing icons and a inability to change the appearance of applications
see https://bugzilla.suse.com/show_bug.cgi?id=920792 for more info.
There are two sensible defaults for this variable, "kde" which will
make apps appear the same as they do if they are run in kde. and gtk2
which will make kde applications follow the gtk/gnome theme, we have
decided on choosing gtk2 as it means that kde/qt apps will follow the
app and icon theme set in the enlightenment settings dialog. Some users
who wish to use Qt apps without any gnome or gtk usage may choose to
install qt5ct and overwrite this variable with qt5ct and use that to
configure there Qt5 applications.
Reviewers: raster, zmike
Subscribers: jeffhoogland, cedric
Differential Revision: https://phab.enlightenment.org/D3498
This function is being used inside e_mod_main, but the function
prototype was never exposed which lead to implicit declaration
warnings when building winlist module
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Summary:
The original next window selection of winlist is weak. It searches the next window with the following conditions:
1. Next non-overlaped window in the direction of user's selection (up,down,right,left).
2. The next window has to be the closest window from the currently selected window (calculated from shortest distance from each window's border, in the direction of selection)
3. the second distant requirement is this:
delta2_next = abs(ec_orig->x - ec_orig->w / 2 - ec->x + ec->w/2);
* Which I believe is a mistake, should be:
delta2_next = abs(ec_orig->x + ec_orig->w / 2 - ec->x + ec->w/2);
These two conditions are weak, and they sometimes can result in unexpected selection to the user.
The enclosed patch enhances the next window selection: 1) A next window selection can be the window that's overlapping with the in-focused window. 2) calculates the next window from the center of the currently focused window to the next window, and it also takes into account directionality (a window that's farther in the direction of selection has a better chance of being selected then a window that's closer in the direction of selection, but offset-ed in the lateral direction.)
Test Plan:
1. Create 4 key binds for "next window to left, right, up, down".
2. Open up 4 different windows and position them in odd/random positions.
3. Try to navigate to each window (with the winlist shortcut keys) before this patch.
4. Try with this patch, and evaluate if the window selection is more **PREDICTABLE**.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2661
I fixed the weridness and it behaves much more reliably now with
"tall" or "wide" windows. also fixed some formatting etc. etc. - this
now works better and now if u alt+tab AND then use arrow keys while
holding alt... it'll navigate around geometrically rather nicely.
so big fixes and good for pointing out the simpleness of the original
code. :)
- raster
@feat
Summary:
damage_buffer posts damage in buffer co-ordinates instead of surface
co-ordinates. For us currently these are always the same co-ordinate
spaces. This will change when we start supporting viewports and
transforms.
Note: this is currently conditional on the macro
WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION which isn't in any
released wayland, but will be in the next. We can remove
the ifdefs and change our wayland version dependency when
it's released
#NefariousHiddenAgenda
Reviewers: zmike, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3468
If we are calling emix_config_save_state_get while in init, we are
freeing the list emix_config_save_state_restore is iterating over.
This leads to crashes.
@fix T2942
@fix T2906
In the xdg_surface_configure_send function, the size params
(width/height) come in as int32_t. This patch makes the E_Shell_Data
fields for width & height match those (else we end up with compiler
warnings when comparing int32_t to uint32_t).
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
desktop gadgets don't have minimum size set from parent objects, so
it's necessary to use the current object geometry in order to correctly
size these gadgets since the top-most widget is from elm
fix T2907
Summary:
Fix missmatched paths between desklock and conf_applications module to
enable adding/removing screen lock applications with a dialog.
Test Plan:
Settings=>Apps=>Screen lock/unlock application
Veryfy if apps are correctly added to config.
Reviewers: zmike, cedric
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3436
when attaching a buffer, it's necessary to have the state available
in order to pull the buffer data into the state for use during commit
fixes subsurface frame callbacks
elm win intercepts this callback in order to maintain internal sizing
for use with elm widgets on the compositor canvas, so it's necessary to
get the callback from this object in order to accurately update the canvas
during resizes
Jean-Philippe Andre
Chris Michael
Mike Blumenkrantz
JengHyun Kang
Yomi
Tom Hacohen
Simon Lees
Toan Pham
Derek Foreman
Stefan Schmidt
Marcel Hollerbach
maxerba
Lukasz Stanislawski
Carsten Haitzler
Chris Michael
