initial "how do i size and lay this out" is a fuzzy algo that tries to
stuff all the windows into a single screen with several rows of
windows (in large mode). it has to trade off sizing for a squarish
layout with mu;ltiple rows so does some passes and tries and bisecting
etc. - the problem is each stage goes and does a lot of object changes
re-laying them out and querying them. this is expensive. this does a
row length calc on its own without the objects to save a whole lot of
overhead.
in theory i could actually skip almost all the object stuf and make
more assumptions and reduce the object fiddliong to just an initial
"how much fluff around a window item in the list and how much fluff
around the winlist (like padding/title and so on) and then just do
some raw math (and even flatten into arrays for cache friendliness).
but it's fast enough right now without a lot of changes. can always
revisit this in future.
this adds a live exposé style set of windows in large mode and 2d
navigation, allows it to stay up so you can bind to a single key or
mouse button to bring up and keep thre unbtil dismissed etc. ... this
requires theme changes and for now these changes have only been added
to the flat theme branch in efl - they will become default in the
future, so dont use this and expect it to work unless you also try the
flat theme default from the flat branch in efl. see
https://phab.enlightenment.org/T6726 for details on that.
this is not complete. it has some TODO items at the top with XXX: but
.. it's good enough now to share.
@feat
we dont need to delay module loading anymore so remove allof this -
priority too shouldn't be necessary as well and was just a workaround.
this remvoes all of that removing some e module api's and module
struct members as well as some global config fields. it also ensures
all config files are up to date as well.
Summary:
Drop deprecated Encoding key from desktop files
The Encoding key is no longer required, all desktop files are assumed to
be UTF-8 encoded. See details at:
https://standards.freedesktop.org/desktop-entry-spec/1.1/apc.html
Fix various typos and misspellings
lintian, Debian's package checker, uses strings to check for common typos
in compiled binaries. This change fixes the ones it identified in 0.22.1.
Reviewers: zmike!
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5585
a reason for doing that is that you can just pack together targets into
a array and pass them to our helper, and the helper will just handle
them, so even module with eldbus codegen etc is now supported.
This also means that we are just passing the src object directly into
the shared_module call, which means the user of our helper can just pack
everything he needs into the src var and the helper does not need to
know about it.
now mdoule build files that fllow one pattern (the most common by far)
all JUSt list their souce files and nothing else. this really cuts
down on build size/complexity.
there are other patterns too (no icons at all) that i'll do next, then
we're down into "weird" land where i'll have to think of some more
interesting ways to deal with this.
so we';re missing installing desktop files. edj icon files, wizard
data files in the wrong place, and much more. this also cleans up the
module meson build of pretty much all modules and make their build
files cimple and consistent so it's far easier to re-use things from
one module to the next. we should aim for simplicity, consistency
between as much as possible so we can refactor and turn into maybe
functions later. imho that starts with consistency though. until i can
see all the common patterns clearly, i don't want to write functions
yet. it's easier to see if all the files are consistently using the
same vars and formatting etc. etc. etc.
but either way the installation needs fixing so it installs all files
in the right places with the right permissions etc. etc. etc.
this doesn't fix all module build files bt all the ones i found that
were broken installs and they use what i think is a cleaner/simpler
template, BUT there is far too much copy & pastage here... far too
much.i need to find a cleaner way to automate this.
So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
now they can be trule async hopefully stopping things like application
menu from stalling while loading icons header... which is really nasty
with svg's. this actually makes icons async by default which is really
EXACTLY what you want. this also prepares for later making edje loads
async.
@feature
in many cases, a mouse action's callback will fail to execute as a result of multiple
objects being under the pointer at the time of the event. in this case,
the callback should be able to determine whether action callback processing should
continue.
as an example, when attempting to execute an action which only activates for
client objects, if the passed object is not a client then the callback should return
false to indicate that it was not able to perform the action for the given object,
allowing further actions to be attempted on this object
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:
Currently the dialogs in Winows > Window List Menu and Window Display are
resizable the their content does not resize. This patch fixes that.
Test Plan: Open windows in window config dialog and ensure they can resize propertly
Reviewers: zmike
Subscribers: raster, cedric, seoz
Differential Revision: https://phab.enlightenment.org/D3275
key handlers here will pick up both wayland and drm engine type events,
so ensure that we only handle events matching the compositor canvas
window to prevent unexpected behavior
fix T2637
if pointer warping is disabled, attempting to pointer warp with mouse-based
focus policies will fail here, preventing focus from being applied as expected
ref T2566
Carsten Haitzler
Simon Tischer
Ross Vandegrift
Mike Blumenkrantz
Marcel Hollerbach
Derek Foreman
Chris Michael
Toan Pham
shorne
Chris Michael