This commit adds the "documentation" generator, which gets the
documentation_def attribute of the given item and generates xml comments
to be exported by MCS.
For items requiring some customization of the generated comments (e.g.
functions and its parameters), the helpers to generate the preamble
(summary), body (paragraphs) and epilogue (currently just the @since
tag) were added.
Currently we do not support converting Eolian references into xmldoc
references.
As we explicitly generate Get/Set methods for properties, for now the
generator tries to get the get/set specific documentation first. If it
is not present, fallback to the common docs.
Later this could be changed to generate the common one as paragraphs of
the Get/Set.
Also some generated code like the wrappers for calling C# methods
from C can be private. This will cleanup the introspection results
and warnings when generating documentation.
Due to this visibility change, the binbuf tests had to be changed
to add redirect calls to the native methods instead of directly
calling the DllImport'd methods.
Summary:
Change name of 'grid' to 'table' for matching on common ui naming
and avoiding confusion with 'gengrid' and 'grid view'.
grid will be introduced as grid image view after.
Test Plan:
checked make & make install
checked make check - there are errors but not related with these changes.
checked make examples - there are errors in cxx but not related with these changes.
checked make discheck - failed
test in elementary_test with Efl.Ui.Table and Table_static.
Reviewers: raster, cedric, jpeg, felipealmeida
Differential Revision: https://phab.enlightenment.org/D5668
Summary:
scrollable widgets had a interface_scrollable as a mixin so that the
widgets had a 'is-a' relation with interface_scrollabe. however, new
scroller concept don't have 'is-a' relationship, but 'has-a'
relationship. scrollable widgets should have a scroll manager inside
them, then scroll manager handles event from user and api
implementations. and also we cut the features such as paging because
there will be aka 'elm_pager'.
we are expecting that the new concept make us to maintain the scroller
easier. please excuse for many unorganized code and logics. : (
[contained commit]
scrollable: add efl_ui_scroller example
scrollable: refactoring for behavior in case of multiple scroller
scrollable: remove repetitive scrollbar code.
scrollable: combine calculating bounce distance code.
scroll_manager: mouse up function refactoring
scroll_manager: mouse move function refactoring
scroll_manager: warp animator wip
scroll_manager: fix denominator value when calculating flicking behavior.
Fix to disconnect bounce animator once animation is done
gather duplicated animator drop logics
gather duplicated conditions
Rearrange prototypes and append comment
Add manipulate functions for animators
scroll_manager: change member_add function.
scroll_manger: apply mirroring logic
scroll_manager: apply scrollbar
apply API to scroller widget
scroll_manager: apply scroll event callback
Change logics for all about scroll animating
efl_ui_pan: add efl_ui_pan
scrollable: change content_min_limit to match_content
scroll theme: apply overlapped scrollbar
+ many others!
Reviewers: akanad, woohyun, cedric, jpeg
Subscribers: jenkins, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5222
Note by @jpeg:
Unfortunately this patch comes in a massive single blob, after too many
rebase operations. It has now come to a point where I think the API is
nice and it works as I'd expect.
Now I only wonder how applicable this will be for Efl.Ui.List. As we can
see Photocam (legacy and unified API) could be transformed to use this
new API.
Summary:
- Previous class efl_ui_bg moved to efl_ui_bg_widget.
- Scale_type moved to efl_image from efl_ui_image.
- Previous enum Efl_Ui_Image_Scale_Type moved to Efl_Image_Scale_Type.
Test Plan:
Run elementary_test
1.Image Scale Type
2.Efl.Ui.Bg
3.Efl.Ui.Win
4.Part Background
Reviewers: jpeg, woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D5616
Summary:
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 1.20.6.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5584
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This resolves a few issues and brings back the experimental features.
Also, disable some of the ugliest experiments:
- manual function overrides,
- define APIs only in eo_cxx namespace
Some APIs are generated behind EFL_CXXPERIMENT (eg. event_name_cb_add or
some weak pointer stuff). I believe they are useful but would like to
make sure there are no serious drawbacks with generating those.
It's VERY hacky, but works as expected: no leak, no extra unref. This is
a lucky case of simply overriding efl_part() implementation in C++,
without having to modify the declaration.
This is part of the experimental stuff.
Allows calling C functions without using ._eo_ptr() explicitly. Probably
not super useful, assuming the interfaces are done :)
I'll hide some controversial features behind this, until we come to an
agreement with @felipealmeida and people who actually know C++ (iow: not
just me^^).
Features protected:
- easy wref (using -> without locking)
- xxx_event_cb_add() functions in object classes
- instantiate(obj) to create a new object
- add as a synonym for instantiate (both in efl::eo)
When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
Note: this is C only, not legacy only.
The problem is that bindings will hold a strong reference to the window,
which will then die "under the rug" if autodel is enabled. This then
leads to at least ERR if not crashes.
Note:
elm_policy needs to support autodel and quit on last del only for C
applications. Bindings will require some other mechanism that doesn't
break all assumptions wrt. references.
The fix is not complete. We need to make efl_part() work nicely in C++:
- Get the refs work properly (maybe without auto-del)
- Generate the parts from the EO file as methods on the object
Final form should be close to:
slider.indicator().format_string_set("%1.2f");
Where everything autocompletes nicely :)
Summary:
9d2dcd92 requires elocation to build.
cxx examples still broken due to elm cleanup
Test Plan: make examples
Reviewers: jpeg, felipealmeida
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5426
make examples now builds all c++ examples but some of them are in fact
empty skeletons. Those either need some c++ love or the final eo api to
be ready (eg. menu, popup, ...).
I removed some examples that don't have an exact equivalent in EO since
the widget is legacy only.
This is more of an experiment than anything else.
@felipealmeida I would like to know what you think.
Notes:
- events still need a better API (event_add isn't part of the object
definition...).
- references are an issue, when you want to actually delete an object.
This isn't meant to be installed. The canvas API in EO is based around
the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is
not EO (eg: ecore_evas, evas, ...)
Note: evas_canvas3d is the last remaining thing that is installed along
EO files, but those are all beta APIs.
Summary:
Currently user ask for the root_node from the evas_vg object and then attach its tree by setting the root node as parent.
With this change this process will be explicit. user has to set the root node to the evas_vg object and the object will take the ownership
of the tree. User can query the current vg_tree by root_node_get api.
Test Plan:
Fixed the test app to reflects this change.
Reviewers: jpeg, cedric
Reviewed By: jpeg, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5347
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
eina_strbuf_append_strftime()
eina_strbuf_insert_strftime()
eina_strbuf_prepend_strftime() - macro
We need these functions for implementing generic format function
interface especially for calander.
Ref T6204
Summary: We should define the windows version before including evil.
Test Plan: Run make examples on windows newer than XP.
Reviewers: vtorri
Subscribers: jenkins, cedric, jpeg
Tags: #efl, #windows
Differential Revision: https://phab.enlightenment.org/D5261
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Reasons:
- This API has been confused with the min size of the widget, resulting
in badly laid out applications.
- The EO API was not very nice (Range is about numbers, the Gfx size
hint in a part is really ugly).
While I understand the value of this API and how it can be used in
scalable applications, it is in fact not absolutely necessary.
Alternatively to that span size, the widget min size can already be
defined from the application side, or the widget can simply be expanded
to fill in its parent.
This can obviously be reinstated later if the need arises for EO. For
now, keep this feature as legacy-only.
I think this closes the orientation vs. direction problem.
RTL vs. AnyRTL is not fully handled yet but this becomes a
widget-per-widget issue (eg. should a box in a RTL locale be mirrored if
set to horizontal?).
Fixes T5870
Summary:
without it, it was failing with following error
/usr/bin/ld: /tmp/ccnjRcVr.o: undefined reference to symbol 'evas_object_move'
//usr/lib64/libevas.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Test Plan: just try to compile it with and without.
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5182
Summary:
Fill in the intro section and the first test mode. (Docs for second
mode will be forthcoming.)
Also drop some of the generic comments that are already explained better
in some of the basic examples.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5201
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
Introduced with commit 13da5e980e
A compile before pushing would have been great, again.
Having the same name for two variables is something no compiler likes.
evas-map-utils-eo.c:74:8: error: conflicting types for ‘r’
int r, g, b, a, f;
^
evas-map-utils-eo.c:73:19: note: previous declaration of ‘r’ was here
Eina_Rectangle r;
^
evas-map-utils-eo.c:93:31: error: ‘h’ undeclared (first use in this function)
efl_gfx_size_get(o, NULL, &h);
^
evas-map-utils-eo.c:93:31: note: each undeclared identifier is reported only once for each function it appears in
evas-map-utils-eo.c:108:25: error: ‘w’ undeclared (first use in this function)
efl_gfx_size_get(o, &w, &h);
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
Summary:
The evas-transparent.c example is quite short, and so will allow for
more detailed explanation of setting up Ecore-Evas. Then
evas-object-manipulation.c can focus more on the explanation of objects
in Ecore-Evas.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5011
Summary:
This is one of the basic examples that introduces Ecore-Evas, so needs
to be more detailed in commentary than other examples. It also points
out the use of the legacy API and directs the reader to the Eo example
where appropriate.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5008
Summary: ecore_main_fd_handler_add is not working on Windows
Reviewers: vtorri, raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4470
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540
Those are now merged with Efl.Object parent, name and comment.
The reasoning is that only seats can be parent devices; And name
and description are not only name clashes but also not extremely
useful anyway.
Tested with VNC.
Fixes T5540
Summary:
This serves as an early example for new Evas programmers to introduce
the buffer engine as well as very basic canvas usage, so we're going
into a lot more detail for both of those than we'll do in subsequent
examples.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4950
Summary:
This is the most basic of the Evas examples and serves as the starting
point for new Evas users. Since this targets neophytes, we can afford
to be much more detailed in commentary.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4904
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Categorize the examples by topic, and identify certain examples as
introductory; these can be commented more verbosely than the other
examples.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewers: cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4903
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
While the API seems to work fine, I am not 100% sure the device
names are properly assigned.
Run ecore_evas_cursor_example or ecore_evas_vnc_example and
then connect to the VNC server locally or remotely.
This was broken since over a year. Happened during the automatic eo4
migration in f21ade6123.
Thanks goes to the gcc warning misleading-indentation:
evas-3d-shadows.c:163:4: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
evas-3d-shadows.c:165:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
evas_canvas3d_node_look_at_set(scene->mediator, EVAS_CANVAS3D_SPACE_PARENT, 0.0, 3.0, 0.0, EVAS_CANVAS3D_SPACE_PARENT, 0.0, 5.0, 0.0);
This implements an entirely new API model for Evas Map by relying
on high-level transformations on the object rather than an external
Evas_Map structure that needs to be constantly updated manually.
The implementation relies on Evas_Map.
To rotate an object all you need to do now is
efl_gfx_map_rotate(obj, 45.0, NULL, 0.5, 0.5);
Or with a C++ syntax:
obj.rotate(45.0, NULL, 0.5, 0.5);
Or even simply (with default arguments):
obj.rotate(45.0);
The map transformation functions are:
- rotate
- rotate_3d
- rotate_quat
- zoom
- translate (new!)
- perspective_3d
- lightning_3d
@feature
In the map examples, the map image UV size was based on the image
source geometry, rather than the image geometry itself.
In the example, this affects how the glass is mirrored. Before this
patch, the reflection is a single line stretched. EFL 1.18 and 1.19
seem to have the same issue, while 1.17 simply fails to show any
reflection. 1.16 fails miserably and the entire window is black.
If the original code was correct, then I believe that map and/or
proxy rendering have been modified in a way that affects the meaning
of those image UV parameters. But this seems like the regression (if
it is one) is in fact quite old.
@fix
Summary:
Also fixes a handful of obvious indentation irregularities,
including some reformatting of some printf() multi-line indents that
commit a71b770b did not properly adjust.
No functional code changes.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4864
Summary:
For people browing through the examples, having the opening statement be
concise and consistent will help them more quickly find what they're
looking for.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Test Plan:
Some of the examples had identical opening statements (e.g. the image
object examples). I've tried to give each a unique description defining
what they are demonstrating, but you may want to doublecheck I got these
correct. Of particular note, to me evas-images5.c looks like just a
fixup to evas-images4.c, so I'm not sure what makes these two distinct.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4861
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Applies same change as e8355c93 for evas, to the remaining examples.
This uses the shell command-line:
src/examples/evas$ grep -sr 'fprintf(stdout' . | cut -d: -f1 \
| uniq | xargs sed -i "s/fprintf(stdout/printf(/"
Note that use of the "fprintf(stdout" construct can generate warnings
when -Wformat-security is enabled, if the fprintf statement has no
format arguments, so in addition to the stylistic simplification this
also helps quell those spurious warnings.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4836
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This fixes all warnings for "make examples" for:
-Wunused-parameter
-Wshadow
-Wformat-security
-Wenum-conversion
Some remaining warnings include:
-Wdeprecated-delcarations
Summary:
Applies the correction purely mechanically using the following shell
command-line:
src/examples/evas$ grep -sr 'fprintf(stdout' . | cut -d: -f1 | uniq | \
xargs sed -i "s/fprintf(stdout/printf(/"
This fixes a few warnings about lack of a format string:
warning: format not a string literal and no format arguments [-Wformat-security]
fprintf(stdout, commands);
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4691
Summary:
The Ecore_Event_Joystick would be not enough information on user side.
Because the button index such as ECORE_EVENT_JOYSTICK_BUTTON_SELECT/START/META,
etc could be mapped to different button for different named joystick.
Test Plan: Using example
Reviewers: raster, cedric, jpeg
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D4669
This is the local socket for windows, analogous to AF_UNIX.
`Efl_Net_Socket_Windows` is the base class doing `ReadFile()` and
`WriteFile()` using overlapped I/O, as well as the close procedure
(`FlushFileBuffers()`, `DisconnectNamedPipe()` and
`CloseHandle()`). These are done on top of an existing HANDLE that is
set by `Efl_Net_Dialer_Windows` (from `CreateFile()`) or
`Efl_Net_Server_Windows` (from `CreateNamedPipe()`).
The overlapped I/O will return immediately, either with operation
completed or `ERROR_IO_PENDING`, which means the kernel will execute
that asynchronously and will later `SetEvent(overlapped.hEvent)` which
is an event we wait on our main loop. That `overlapped` handle must
exist during the call lifetime, thus cannot be bound to `pd`, as we
may call `CancelIo()` but there is no guarantee the memory won't be
touched, in that case we keep the overlapped around, but without an
associated object.
Windows provides no notification "can read without blocking" or
non-blocking calls that returns partial data. The way to go is to use
these overlapped I/O, with an initial `ReadFile()` to an internal
buffer, once that operation finishes, we callback the user to says
there is something to read (`efl_io_reader_can_read_set()`) and wait
until `efl_io_reader_read()` is called to consume the available data,
then `ReadFile()` is called again to read more data to the same
internal buffer.
Likewise, there is no "can write without blocking" or non-blocking
calls that sends only partial data. The way to go is to get user bytes
in `efl_io_writer_write()` and copy them in an internal buffer, then
call `WriteFile()` on that and inform the user nothing else can be
written until that operation completes
(`efl_io_writer_can_write_set()`).
This is cumbersome since we say we "sent" stuff when we actually
didn't, it's still in our internal buffer (`pd->send.bytes`), but
nonetheless the kernel and the other peer may be adding even more
buffers, in this case we need to do a best effort to get it
delivery. A particular case is troublesome: `write() -> close()`, this
may result in `WriteFile()` pending, in this case we wait using
`GetOverlappedResult()`, *this is nasty and may block*, but it's the
only way I see to cope with such common use case.
Other operations, like ongoing `ReadFile()` or `ConnectNamedPipe()`
will be canceled using `CancelIo()`.
Q: Why no I/O Completion Port (IOCP) was used? Why no
CreateThreadpoolIo()? These perform much better!
A: These will call back from secondary threads, but in EFL we must
report back to the user in order to process incoming data or get
more data to send. That is, we serialize everything to the main
thread, making it impossible to use the benefits of IOCP and
similar such as CreateThreadpoolIo(). Since we'd need to wakeup the
main thread anyways, using `OVERLAPPED.hEvent` with
`ecore_main_win32_handler_add()` does the job as we expect.
Thanks to Vincent Torri (vtorri) for his help getting this code done
with an example on how to do the NamedPipe handling on Windows.
While in UNIX we use 'select()/poll()' to query for read fds and this
will eventually callback with "can_read" event, use the loop to match
other implementations where can_read keeps true if not all data was
read.
Cedric BAIL
Jean-Philippe Andre
Vincent Torri
Carsten Haitzler
Felipe Magno de Almeida
Lauro Moura
SangHyeon Lee
Wonki Kim
Sungtaek Hong
Vitor Sousa
Amitesh Singh
Ross Vandegrift
Jaehyun Cho
Daniel Kolesa
Prince Kumar Dubey
subhransu mohanty
Subodh Kumar
Stefan Schmidt
Bryce Harrington
Daniel Zaoui
Guilherme Iscaro
smohanty
Jeeyong Um
Andrii Kroitor
Al Poole
Shinwoo Kim
Gustavo Sverzut Barbieri