Nathan Ingersoll a écrit :
Hisham,
I am only responding to your criticisms on EWL in this message, as I
have already stated that I don't have a problem with people wanting
to write their own toolkit.
On 10/23/05, *Hisham Mardam Bey* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello,
We have noticed that Ewl lacked (at the time of creating Etk) in the
following departments: 1- Menus: Ewl menus do not function like one
would expect. This is partially due to an incomplete implementation,
and partially to several existing functionality bugs and unexpected
behaviour (no mouse / keyboard grabs, improper submenu popups
requiring mouse clicks, size calculation problems, and screen
location problems; in or off screen).
Did you ever ask how difficult this would be to fix? I just committed
an approximately thirty line addition (at least 8 of which are
comments) that takes care of the mouse/keyboard grab issue. This also
solves the problem in the generic window case so it is applicable
beyond menus. Mouse navigation works that way because that is what I
have taken the time to implement. Each widget gets their own
mouse-over event, if you want it to trigger a timer that kicks in the
submenu expansion, again, this is a pretty small change. Key event
callbacks work but have not been implemented yet for the menu.
Your patch doesn't seem to fix anything here. Now, the situation is even
worst, I can't close anymore the menu by clicking anywhere on the parent
window, I always have to click on a menu item. And keyboard navigation
is more than just making a printf each time you press the up or the down
arrow.
2- Themeing / Look and Feel: Ewl tends to re-use a lot of parts for
several "similar" tasks but eventually ends up looking bad. For
example, buttons are used for column headers for trees and for
scrollbar drag buttons. Combining this with a lot of scaling and size
calculation problems yields bad visual results. The entire look and
feel of Ewl applications feels strange and clunky. This has been
commented on by the likes of Raster, Vrln, and several other people.
A lot of work needs to go on how Ewl applications feel and react to
and with the user.
Column headers ARE buttons. The complaint you have is about theming,
and as I've said before, there is plenty of code to write and I tend
to get lazy on the themes. I think I have mentioned and asked for
help enough recently to make this point. The themes are designed to
allow for re-use as much as possible. You can map multiple widgets to
a single edje or override the theme for a specific part at any given
point in the widget heirarchy.
If it's possible, why don't you allow the themability of the scrollbar
drag buttons or of the tree headers independantly of the button? If you
don't have time to work on the theme, then just do a copy-paste of the
button group and rename it as scrollbar_drag and tree_header. At least,
it will allow themers to make a correct theme without having to change
the ewl C code.
3- Alignment, Clipping and Size Calculation: Labels and buttons are
not properly aligned (refer to labels next to checkboxes or radio
buttons). Buttons with an empty label have no height no height.
Simple things like size calculation and clipping for atomic widgets
do not work properly. Resizing any Ewl application is expected to
generate undesired clipping and size calculation (look at
e_util_eap_edit or ewl_test and notice how resizing the window
rigorously causes this).
Fixed the radio and button alignment, thanks for the reminder as I
had forgotten to do that. Guess what? That was a 4 line patch (2
lines if you use ETK style line wrapping). Resizing a window causes
size recalculations? Well, it causes the widgets to be laid out again
to fill the space better, it doesn't involve widgets recalculating
their preferred amount of space. Why should a button with no contents
be the same size as a button with contents? How is an empty button
even useful? What if you have different font sizes in your labels, do
you want them to calculate at the same size? Undesired clipping could
be the result of a size miscalculation, please report where you are
seeing this (it could be clipping based on fill policy, which is
entirely valid). This laying out of widgets is not causing any major
overhead when resizing a window. Try profiling it once, on a normal
window layout and EWL is way down the list when sorted by function
overhead.
Great for the radio and check buttons alignment thing fixed, even if
there is still the problem with the normal buttons.
6. Tree Widget: The tree widget needs a serious rewrite. Nathan has
recently mentioned fixing it. For now, all the rows are composed of
several widgets, including the hidden rows. This means that when you
have 3000 items in the tree, you have over 3000 widgets created, and
so thousands of Evas_Object's created. Evas was not designed to
handle so much objects, even with the widget pool it will not work so
well. Ewl's tree widget insists on maintaining the ability to hold
any type of widget. We disagree with that concept and would rather
have our tree hold only specific types of widgets to allow for
extremely optimized performance.
The primary reason for the rewrite is to make data manipulation
easier on the end-user as multiple people have had some difficulties
using it. I don't find it fatally flawed, but I did learn from the
experience and have ideas on how to improve it. While EWL does create
three widgets for each row (if you use the row_add functions, not if
you are using a single column with the container functions), these
widgets are also not touched after initial creation until they are
expanded to be visible. So you do have the initial overhead of
creating them, and the memory used, but beyond that they do not
impact the system until expanded. There are also no extra Evas
objects created until the widget is realized. This can't happen until
it has become shown.
You're right that Evas doesn't handle a large number of objects
(>3000 or so, depends on your hardware) very well. I don't think this
is a reason to not allow arbitrary widget packing in a tree. I don't
believe I had mentioned a widget pool before, it was more of
on-demand widget creation and destruction. Assuming that's what you
meant, why wouldn't this work well? Making a blanket statement
without backing it up with logical reasoning doesn't make it fact. It
appears (I haven't looked at the code) that ETK uses a fixed size for
each row and uses that to make assumptions on it's layout. If the MVC
model allows for hinting of fixed size set of rows and retrieving the
number of rows available (which has been part of the plan), does that
not allow for the same assumption for layout calculation when
appropriate but allow the flexibility of not using varying size rows
when appropriate? I won't claim that the performance will be
identical to assuming fixed size in all cases and using Evas objects
directly, but I don't think it would be at all unreasonable.
Here I fully disagree. I played a little bit with ewl_tree_test, and I
replaced the ROWS constant by 3000 (it was initially to 50) and I
removed the NEST modulo just to make sure all the rows will be directly
children of the tree itself (no collapsed rows). Result? It takes
approximatively 2 mins for the window to appear, scrolling is laggy as
hell, and (I don't why) it caused the shutdown of ewl_test after 30 secs
of use (no segv, just a shutdown). And hopefully, you've coded a
function to know the heap size. So here is the result: "HEAP SIZE:
71053312 bytes". Yes, more than 70Mb for 3000 rows. And I don't see how
you can improve the situation without limitating the type of widgets you
can add to the tree. Even if "2950 * num_of_rows *
num_of_evas_objects_by_widget" evas_objects are hidden, they are still
processed by the rendering pipe of evas, and worst they still remain in
memory.
Regards,
Simon
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
