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]> 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.
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.
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.
4. Keyboard Navigation:
Ewl has been missing keyboard navigation and general keybindings that
are normally expected among toolkits. Until recently this has not been
present, we noticed some code about focus / keyboard navigation, but
nothing works so far.
Yes and no. There have been keyboard callbacks present for a long time and the structure for keyboard navigation was initially added quite a while back. dan has been working on flushing this out more and getting the functionality in working condition.
5. Fill policy:
The fill policy system seems to be too complicated and new behaviour
is noticed on a regular basis. This has been shown by the countless
times applications like Entropy had to deal with that and simply
"tried" until something worked the way it should.
Personally, I don't find it that complicated to use, and I recently added a small change to two functions that made it much more intuitive (I checked with chaos and he agreed on this point), but it can be a little tricky sometimes. This is your first point that even starts to address design issues as the fill policies are part of the base design, but is the problem one of design or current semantics?
Basically, a fill policy is either shrink or fill in the horizontal and/or vertical direction. If you have have fill set, and the container holding the widget has extra space for that widget, the widget will accept the extra space up to it's maximum size in that direction. If a widget has shrink set and the container doesn't have enough room to give the widget it's preferred size, the widget will accept the smaller space down to it's minimum size.
These policies are also used to determine if the parent container needs to be notified of a change in size. If a widget has fill set and the current size is greater than the new preferred size, then no notification is sent to the parent, same idea for shrink and a smaller size.
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.
7. Rewrites:
Ewl has been re-written and patched up for quite a while. With all
those iterations, a lot of extra complication and overhead has been
introduced. What is currently being noticed is that entire widgets are
being re-written from the ground up, or fixed massively. Since all
that effort is being put in, and we already have problems, there's no
reason we this cant all start from scratch and become better.
Bullshit. It has been rewritten, but none of the rewrites are the current code base. The current code base is the evolved (patched if you want to call it that, I'd call it developed) original code base. A lot of extra complication and overhead? Such as what? This is more blanket statements without facts. What has been rewritten? The text code is about it, and that's been to handle many changes in the text layout backends. The most recent change was an update to work with tb2, this wasn't a rewrite but an update. The last text rewrite was so we could maintain formatting data across textblock creation and deletions. There has been shuffling of code lately to provide what we consider more consistent and cleaner APIs, but not rewrites. Even the tree code is not a complete rewrite from scratch, a lot of the internal data handling will be different, but the decorating portions won't change much.
You can go right ahead and write your own, no one is going to stop you and I don't especially care if you want to design something that is more to your liking, but you're making attacks on EWL's design with arguments that have such huge logic gaps or missing information that it's basically impossible to logically argue with them.
So far the only real design point (and that's arguable) you've made is that you don't like the way fill policies work. Otherwise, you've done an excellent job at pointing out bugs or missing functionality.
Thanks,
Nathan
