Subject: [E-devel] [PATCH] elm_icon is disappeared when theme hook is
called.
[Current Issue]
- The elm_icon can be disappeared when theme hook is called.
You can see the problem in the below situation.
a) elementary_test -> Layout select
b) elementary_config -> Fonts(toolbar) -> select some font
class, font,
style, size
c) Select "Apply" button
then two icons in title layout are disappeared.
[Main cause]
- when theme hook is called, internally
_elm_image_smart_sizing_eval
function is called.
The function calculates icon's min, max size.
But min, max size is calculated only in case no_scale is true or
resize_down or resize_up is false.
If application isn't set no_scale or resize_down/up, minw and
minh value
is just -1.
So when theme hooks is called then sizing_eval is called, icon's
min size
is -1 and that is disappeared.
[Change Description]
- I just added evas_object_size_hint_min_get(obj, &minw, minh) in
_elm_image_smart_sizing_eval.
Patch is working well, but I don't think this is right solution
because
that would break image(icon) min,max concept
SVN revision: 74163
Allows setting a trap in elm_win that intercepts calls to
ecore_evas. If there is a trap and the trap returns EINA_FALSE, then
the corresponding call is NOT issued. If it does not exist or returns
EINA_TRUE, then the call is executed.
Enlightenment window manager will set these traps and will call
e_border directly, allowing E17 to use Elementary! A major feature
given e_widgets painful usage.
This should also help integrating into Wayland or even debug.
SVN revision: 74156
widgets.
Some of them have initting code using the parent ptr for some logic.
Now there's a new idiom on instantiating widgets which adresses
that. It'll be used for all widgets from now on.
SVN revision: 74147
When smart obj was set as the contents the _configure would be called recursively.
In this process the lastest size could be reverted as the previous one.
SVN revision: 74064
Subject: [E-devel] [PATCH] Add frame size when calculating minimized
elm_win size
Hi,
I found frame size including width and height isn't counted in
_elm_win_resize_objects_eval() when calculating minimized elm_window
size.
It is OK for X engine because elementary only draw client area and X
provides widow frame. So both the width and height from
evas_output_framespace_get are 0.
But it cause bug for wayland engine because elementary need draw
window
frame by itself. So real client area size is smaller than window size.
If frame size isn't counted into minimized window size, there isn't
enough client area to layout widgets.
So it is bug for any engine in which elementary draws window frame by
itself. It is the reason of
http://trac.enlightenment.org/e/ticket/1064.
Could you please my attached patch for this issue?
Thanks.
SVN revision: 74049