additionally, this ensures that clients that cannot be layouted are
definitly outside the tree. Without applying the window tree again.
With all this tiling can be used quite normally. If you want to know
exactly what is going on, set notify level to info, then tiling tells
you what cannot be tiled.
This reverts commit 265c306874.
This is somehow the wrong way of doing that. Next commit will bring
protection against multiple recursive window_tree_apply calls.
Additionally, we should prepare to *not* accidently tile a window that
has been previously untiled.
so some clients just cant tile due to min size and this leads to
really bad results so pass the problem back to the user to go resize
them up to fit. this probably needs far more extensive layout logic.
the data struct is a tree but perhaps it needs to flatten out into a
table to make layouting more sane. but that's the future. for now be
less bad today.
if we use the util func we do get a title... and als use translation
too for this notification. Also increase timeout so people can read it
and notice it.
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
the problem here was that in the initial case the function got the
previous state of the tree wrong, so the insertion of a second client
ended up in a unpossible state of the tree, this should not happen
anymore now.
The insertion is now also way more stable, since in a errorcase the
client is not just not placed in the tree but associated with a window
tree, its just not placing the client in the window tree at all.
when plugging a screen in and out, there is the case that a zone has a
usefull geometry of 0x0, which means all clients on this zone are
resized to 0x0. Which leads to a CRIT message in the compositor, which
leads (ref commit 5d875e6a3d) to a abort()
which is really really annoying. Give here a short ERR about that case
so we are leaving out the compositor, since this really only strikes on
tiling, since in normal mode the client just keeps its size.
there is no event that indicates that the mouse went to a other zone. To
solve this we simply update the current split type each time when
changing or using the type.
If someone starts to drag a client arround, then the client will shrink
into a icon, that now is always at the position of the mouse cursor, if
the drag ends, the client will be placed in the client currently below
it. The client will be placed in a place where the mouse cursor was
currently closer to.
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
Otherwise the popup will be where you are not looking at.
This patch adds a new function to e_comp_object where you can pass the
zone where you want to place the e_comp_object on.
ref T4499
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
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
This broke with the change to elm (so within this release cycle). Tiling
wasn't properly detecting windows who become centered after creation as
there was no e event for that. This is now fixed, and a blanket solution
for similar gotchas has been implemented (otherwise known as a hack).
Thanks to Mike for helping out.
Marcel Hollerbach
Elyes HAOUAS
Carsten Haitzler
Ross Vandegrift
Mike Blumenkrantz
Marcel Hollerbach
Derek Foreman
Tom Hacohen
Chris Michael