On OSX the framespace and CSD (Client-Side Decorations) are not
supported at all... I am not able to test this case. This patch
restores the main menu functionality based on pre 1.19 themes,
where it was located inside win.edc (app content) and not in
border.edc (framespace).
Note that the initial size of a window may be wrong, eg as in
elementary_test -to "Main Menu"
Fixes T5734 (hopefully!)
in x11 the mouse pointer is separate to everything else on the screen,
and so when screensaver kicks in and we fade to/from black or we
suspend/resume and do the same... the mouse pointer stays annoyingly
visible and it just lookes like a bug. this allows that to be fixed by
allowing the pointer to be suspended or resumed... :)
@fix
for compatibility reasons this can only be changed in a signal callback
in the default theme.
all themes should now use NOGRAB for parts which can be used to trigger
window_move signal bindings
ref T5552
Previously the progressbar in fileselector use hardcoded style name
"wheel", that made unpossible to create different style for
fileselector. This commit made it possible.
@fix
Summary:
When auto update is enabled, the label of the hoversel will be that of selected
item. This feature is usually used when changing state of something.
Highlighting item previous selected will show what is current state more
explicitly especailly hoversel has many items.
Test Plan: elementary_test -to hoversel
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4799
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
In singleline textblock, using "text.min: 1 0" and min, max width,
Edje allows to use expandable text with ellipsis. It shows ellipsis
when only text's width reach the max width.
But, Edje couldn't support same feature on multiline textblock.
Edje dose not use max height or text.max properly if ellipsis is enabled.
This feature is very useful to make a layout with dynamically aligned text.
@fix
Reviewers: cedric, tasn, woohyun, raster, herdsman
Subscribers: z-wony, eagleeye, jpeg
Differential Revision: https://phab.enlightenment.org/D3595
* make the 2 monitors fill based on tx/rx percentage vals
* try a more bluish version (still need a bit of love)
Note that this is not working atm (okra need to fix in E)
This reverts commit 5eef9da416.
This breaks full rebuilds with the following error (Jenkins logs):
00:25:40 configure: creating ./config.status
00:25:41 config.status: creating Makefile
00:25:41 config.status: error: cannot find input file: `data/Makefile.in'
This also broke incremental builds with a different but just
as confusing autofoo error message.
Summary:
When width of parameter(w) is bigger than or equal to scroller's width(pw),
scrollable object must be scrolled to x position.
Test Plan: elementary_test -> focus 4
Reviewers: woohyun, SanghyeonLee, Hermet, cedric, jpeg, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4491
The frame object requires a theme of version 119 or more. In fact
I think until we are totally happy with the window API (for EO) we
might want to bump that version regularly. That would indeed disallow
theme customization for border.edc until it's done.
This patch uses a pretty brute force way to set the theme file to
the default file from EFL installation. elm_config is not reliable
here.
This is very custom made and there may be a more generic way to force
a widget to use a minimum theme version. Yes that could mean ugly
widgets if we change the theme API but at least that would make them
work. Note that the border theme contains no visual elements, so the
colors of the background, etc... should all depend on the user
selected theme. But of course CSD (in Wayland) will have to use the
default theme -- and look grey.
Fixes D4976
Like 79d76fb25e, this is useful when
debugging a core dump.
It accepts a valid pointer to an object, for example as returned from
$eo_resolve, and a name of a class or mixin, and returns a pointer to
the private data. Essentially the same as efl_data_scope_get(), but also
works on core dumps, and accepts a class name instead of a class
pointer.
Usage:
Print the pointer:
(gdb) print $eo_data_get($eo_resolve(obj), "Efl_Canvas_Object")
$1 = (void *) 0x555555eb9290
Use it directly (e.g. to print a value):
(gdb) print ((Evas_Object_Protected_Data *) $eo_data_get($eo_resolve(obj),
"Efl_Canvas_Object"))->last_event_type
$2 = EVAS_CALLBACK_MOUSE_UP
@feature
After reverting 8a21384759, I figured out how to move
the main menu back to the border group. This time the menu is in the
framespace and its layout algos have been adapted to allow non-zero
root coordinates.
Summary:
elm_calendar is not subject to current automated focus policies due to internal implementation issues.
(Each date in the calendar is an edje part. )
For the above reasons, I have implemented the focus policy support manually.
Test Plan: elementary_test - calendar sample.
Reviewers: bu5hm4n, woohyun
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4421
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
As Andy reported, the main menu geometry is not correct after
my recent changes, as the application contents slide underneath
the menu bar. In fact the menu bar is just floating above
everything else.
So I've tried to move the menu to the framespace (as it should
belong to the frame), but the sizing algos for both the window
and the menu make some assumptions that render this task quite
difficult. Eventually I would like to be able to swallow the
menu somewhere else inside the border... but not right now.
Thanks @raster for pointing this out: title bar and menu bar
were resized down to 1 pixel high rather than 0. This meant that
all CSD windows would see a 1-pixel line between the title bar
and the app content, while SSD windows would see a 2-pixel line.
Also clip out the icon, this makes a 1x1 pixel disappear from the
top-left corner.
My previous patches have broken E Wayland internal windows, as
the compositor wants to create Server-Side Decorations[1] but
based on some mysterious heuristics, E will decide to show or
not SSD. It seems the surface geometry, window geometry,
input region and maybe opaque region need to all match. There
was a pixel difference in the theme which broke everything,
also CSD shadows must be turned off in that case.
This also fixes inputs as for some reason a mismatching input
region vs window geometry would break pointer move/up/down in
those internal windows.
[1] I believe this is not a great idea and E should never draw
any server-side decorations in Wayland. Wayland was supposed
to mean only CSD, no more SSD.
For standard windows, we want to create an elm_bg object if
the theme is a legacy one. Otherwise the default theme
doesn't require an extra object, just a rectangle.
This fixes compatibility with legacy themes (ie. every single
theme in existence beyond the default one, for now), by checking
where to swallow the menu widget. If a legacy theme is used,
the legacy swallow should be used, and it will all look correct.
Moving forward I hope to get rid of the internal edje object
entirely, except for compatibility reasons.
Also converts border.edc to lazEDC (easier to read, imho).
This is still work in progress but currently this supports
CSD & no-CSD modes for normal, maximized, main menu usage, shadow
on and off.
Note that shaded support is not implemented. I've made some
attempts towards this goal, with some success under X but it
was ugly code, and didn't work under Wayland (weston). So, no
extra support for shaded mode yet.
Use Efl.Part for window to manipulate the background.
Two part names are used in EDC:
- elm.rect.background
- elm.swallow.background
For apps the part name is only "background".
To set a solid color background (alpha is ok):
efl_gfx_color_set(efl_part(win, "background"), r, g, b, a);
To set an image:
efl_file_set(efl_part(win, "background"), "image.jpg", NULL);
To set an object:
efl_content_set(efl_part(win, "background"), subobj);
The solid bg is invisible by default, will become visible and use
COPY render mode if a color is set. Standard window uses the
swallow part.
@feature
Normally when debugging Eo with gdb you can just use any of the internal
eo functions to resolve the id to its internal pointer. However, when
loading a coredump you can't execute any code, not even the id resolve
code.
This change adds a gdb function that resolves the id to its pointer form
without executing any code in the process space. This plugin is
essentially the id resolve code written in python as a gdb function.
Usage:
Print the pointer:
(gdb) print $eo_resolve(obj)
$1 = (_Eo_Object *) 0x5555559bbe70
Use it directly (e.g. to print the class name):
(gdb) $eo_resolve(obj)->klass->desc.name
This plugin requires that the coredump would be loaded with the exact
same libeo.so binary (or at least one that hasn't changed eo internals),
and that the debug symbols for libeo.so would be available for gdb to
use.
Note:
This feature is incomplete and only resolves IDs that are owned by the
main thread and in the main domain. This is not a big issue at the
moment, because almost all of our IDs are like that.
@feature
Stephen 'Okra' Houston
Mike Blumenkrantz
Carsten Haitzler
Jean-Philippe Andre
Davide Andreoli
Andy Williams
Vyacheslav Reutskiy
Jeeyong Um
Amitesh Singh
Youngbok Shin
Bruno Dilly
Gustavo Sverzut Barbieri
Hosang Kim
Tom Hacohen
Jee-Yong Um
Woochan Lee
Amitesh Singh
Daniel Zaoui
Stefan Schmidt