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 their build fiels are super easy to maintan. we should expand this
kind of ptterning aross the e build and then expand it to handle new
patters where needed like custom binaries (setuid or not), etc etc.
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
segv if u go do make installs that install desktop files causing
efreet to recheck desktop files causing e to reset desktop files
causing ibar to refill icons but this causea a segv if a hover menu of
windows for that icon are up at the same time. this fixes that.
@fix
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
the sizing issue in all of these tickets was caused by the "empty" object
being deleted, thus allowing the box to reset to 0x0 size hints and
returning this value as the overall size during recalc; the result is that
all icons would be sized at 0x0 instead of using the preserved orient size
as expected
fix T4509, T4647, T4830, T4733, T4524
the assumption that this code was making assumptions about elm_box
internals based on a shallow reading of the code was incorrect, and
the resulting "fix" (and subsequent attempts to bandaid it) has left these
gadgets in an unusable state for the past half year.
disappoint.jpg
this reverts the following commits:
f97f8f61acebfa4a97cd50030dc69342aa6be359504706d45ab1f608c5e6b107dc1cdc3fc195cd9f
There are two cases, on a shelf and on the desktop.
If on a shelf we are using the height setting of the self, since max.w
max.h are only set after a few calcuations, and the gadget does not get
moved on a shelf which does not fade out, so the first min size
calculation must be correct.
If we are on the desktop max.w and max.h are not always 0.
There were some cases when none of this conditions are met. So this
patch enforces a mimum size of 40x40 pixels.
so... when ibar/ibox were ported to elm box they assumed elm box would
resize itself. this was wrong as it only should have set min size
hints. this has been fixed by 96fbea9daecf7040ac63203c4823722fa6d5d73f
and this addresses T3031. this requires we fix enlightenment too.
@fix
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
valgrind pointed out a referencing issue with the ibar client menu on
hover and if e is shut down while this is up. it ends up referencing
an already deleted ibar icon, so delete the menu objects that
reference the icon if icon is deleted.
@fix
i encontered a situation where the icon_hash contained a garbage entry
- had been freed already. the only way i can see this happening is if
the desktop file changed path during runtime thus the icon was never
removed from hash on free as string didnt match. store string used
when adding to hash so removal is guarannteed to work and also for
good measure protect against double-adding (and generate a new string
for storage using timestamp which should be unique).
so this fixes a crash i was just looping on.
@fix
previously, beginning a drag with the left button, then pressing and
releasing another button would result in the drag terminating without
the original button being released
when attempting to drop on an icon, the drop area geometry was never included
in the calc, resulting in the drop changing between positions on every frame
Mike Blumenkrantz
Marcel Hollerbach
Carsten Haitzler
Derek Foreman
Chris Michael
