This method will force a read-write cycle and returns if it's fully
done or not. It may be used to force data to be written before a
handle is deleted (when one can't wait for the data to be written
asynchronously).
E Wayland internal windows are a special beast. Somehow all their
events are intercepted by a special input_obj... but never get
propagated back to the elm_win.
Major side-effect: you get 2 window decorations. I believe there is
some dark magic inside E that tries to figure out when to show
a decoration and this conflicts with CSD.
But hey, it's late so I want to "fix" this and figure out the details
later.
elm_suite would crash when CK_FORK=no is set, because evas was
badly initializing or shutting down. Note that elm_suite still
crashes with CK_FORK=no but valgrind doesn't complain.
Func _eina_file_win32_first_file try to find the first file in directory
but if any file not found the file handler stay open, and func will
return error. But in this case while handle is open impossible to do
any actions. For example call eina_file_ls for empty folder, func will
return error and fold folder open. And if we try to remove this folder
Windows only mark it to delete, and remove it after the process is
complete.
Solution: close handler in error case.
if there is a event the callback counter should be incremented not
decremented. This should fix a few crashes i found in edje, since edje
did not knew that a element was deletion.
This series of patches include:
1. Add experimental Client-Side Decorations (CSD) mode for
windows on X11 (enabled with EFL_WIN_FRAME_MODE=on).
2. Use Efl.Part to set the content and background of a window.
3. Begin moving elm_win_resize_object APIs to a legacy-only
set of features.
4. Add a new stacked box class.
5. Fix modal windows.
More patches will follow, to implement support for the conformant
features right inside elm_win, as well as polish existing features.
I am merging this now in order to spot and fix compatibility issues
as early as possible. This patch indeed reworks a lot how the
window and its edje groups work together.
Unfortunately, unless we created a new Window class, the complexity
of the code inside efl_ui_win.c has to increase. On the other hand,
all windows now have a frame object, except fake windows, which
redudes some of the differences between X11 and Wayland.
CSD are not used by default, as their support is still not complete
on X, and totally unimplemented on other platforms (OSX, MS Windows,
etc...). Eventually we could think of moving all windows to use CSD
mode like GTK3 does nowadays.
Note: The theme ABI is changed A LOT, so this may break compatibility
with older themes (I have tested a bit, though^^).
@feature
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.
This simplifies the cases by adding a border edje on all
windows except fake (damn fake windows). Shadows and borders
are always disabled on such windows (but we could easily change
that in the future).
The idea is to not have resize object in a stack anymore,
but a couple of swallows in the frame and if the stack of
resize objects is wanted, then the user can still explicitely
create it.
This fixes invalid mouse cursor used when windows are
created.
Due to the changes in the border theme and the fact that
a border is now always created, the event region
"elm.resize.bl" contains the point (0,0) when the window
size itself is 1x1. As a consequence every EFL application
would permanently have a cursor like the resize bottom/left
handle.
This fixes that by properly checking whether the pointer is
inside an object based on the ins list, and not just the
object geometry.
@feature
See also: b735386a45
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.
All windows, except for fake, inline & socket images,
should have a frame object to handle all the new APIs and
slots (background, content, indicator, etc...).
The theme will need to handle various modes:
- full CSD
- solid CSD without shadows
- server-side decoration (borderless without shadows)
- borderless with shadows
This means that the default theme must be used for windows,
so that the required edc parts exist. Apart from the standard
background, it is very unlikely that a theme will have changed
anything in win.edc, conformant.edc or border.edc.
This might prove a controversial move, but the alternative would
be to have increasingly complex code handling new themes with
a single edje object and older themes by swallowing tons of
components magically.
Eventually, the win edje object should also not be used anymore.
By default, windows should not have CSD enabled, except on Wayland.
This patch does not handle frame_obj with server-side decorations
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
This is for client-side decorations on Xorg.
Mouse-based move and resize of the window now work fine, but
there are still a few glitches:
1- GL resize is awful (nothing much we can do)
2- Move/resize requests trigger a focus out event,
this in turn changes the style of the window from focussed to
unfocussed. This is thus different from what we see in Wayland
(no focus state change at all) and in usual X11 (focus changes,
but the frame keeps its focussed style).
To counteract this effect, we prevent the frame from changing
style on focus,out if we know we are moving or resizing. But
we don't know that if the compositor moves/resizes (eg. with
Alt key); The focus event happens too early, before the move
or resize events. At least in E.
Gustavo Sverzut Barbieri
Jean-Philippe Andre
Vyacheslav Reutskiy
Stefan Schmidt
Marcel Hollerbach
Hermet Park
Stephen okra Houston