[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]



There were at least 2 cases of discussions on IRC that went something to th=
e
effect of:

<MoOm|CodeWarrior> EWL needs to be rewritten
<RbdPngn|dj2> why?
<MoOm|CodeWarrior> because widget foo does bar, and it shouldn't

Next day a 2-5 line commit goes in fixing the case of widget foo doing bar.
This is not going to be the case for every issue of course, but it certainl=
y
points to a tendancy on their part to prefer a rewrite over actually lookin=
g
for the bug fix.

2) By starting over, we lose the collective knowledge that is in EWL.
>
> 3) Current EWL development has focused on moving to new API's
> (textblock2 e.g.) and optimizing low leve
> l performance (object cache, etc). The display bugs with the individual
> widgets, although more noticeable to the end user, are less important at
> the moment.


The object cache work has been very important (even though most of it has
not been merged yet) as it lead to the discovery of other places we could
save memory and widget setup. I would say 3x speedup loading large
directories would qualify as noticeable to the end user. Most of the layout
issues I've seen are the result of some confusion on the fill policies. I
believe the biggest issue is from one or two of the containers rebuilding
their preferred size in ways they shouldn't.

So, now we find ourselves facing a difficult point. Very few of us have
> put forth any effort to learn EWLs internals, and thus, judge it based on
> the feel of an ewl
> application. Ostensibly small issues with
> packing box layout and text box cursors (and the default theme, which I
> spent all of an hour on one weekend a few years ago...) make it feel
> unprofessional.


You're right about the looks, I've changed the default theme to the e17 for
now to give it a better match to the default window manager look. I don't
know how many times I can say it, but WE NEED HELP THEMING! I am decent wit=
h
basic graphics, but given the choice between working on code and working on
the theme, the code always wins. A lot of the default theme is just hacks I
put in place so I could see the results of the code. The e17 theme is at
least better than that.

It seems as though no one who proposed a rewrite had taken the time to
> truly learn EWL's internals and
> point out the design flaws that warranted a complete rewrite. But, on
> the same token, if the plethora of layout issues are really in the higher
> level widgets, why have theynot been fixed over all these years?


Good question, and there only one answer I can give you: it's my fault. The
base of EWL has been changing and evolving, making it very difficult to hav=
e
a stable API to write higher level widgets on top of and to debug some of
the issues with lower level widgets. It has stabilized a fair amount over
the last year which has allowed us to work out more of the layout issues.
There has been a ton of work put into increasing code re-use as much as I
can and that has impacted assumptions that other programmers can make as
well as made debugging more difficult for some cases.

I can't answer, as I also have little idea about the inner workings of EWL.
> However, I do think that IF a rewrite IS necessary, we should discuss
> the reasons openly, and not slap long time developers in the face with a
> project that completely supplants their baby.


The project aspect I really don't care that much about. They're welcome to
do their own toolkit project, there are plenty of them out there and it's a
good learning experience, but the fact that their motivations seem so
misguided and that they have been attacking work that they admit to knowing
little about, that bothers me a lot. Yes, EWL is my "baby" but I'm very ope=
n
to suggestions on how to improve it. This is why I've asked MoOm and
CodeWarrior to PLEASE (yes, I'm asking again) point out what the design
issues truly are if they see some. Then we can do an evaluation to determin=
e
if the issues are such fundamental flaws that changing the current code bas=
e
doesn't make sense.

So, I'm holding off judgement. I agree that from a users perspective,
> EWL leaves a lot to be desired. But, I've yet to be convinced that this i=
s
> due to any fundamental design
> flaw in EWL that warrant a total rewrite. (The majority of the visible
> issues seem to be h/vbox layout problems to me -- but again, I don't know
> enough to really say).
>
Okay. Enough of my rambling. I just want to get this out there so we can
> start some real discussion and
> make a real decision, that even though painful to one side or the other
> is at least explained and justified...


Thanks rephorm, I appreciate the fact that you at least want some solid
reasons before throwing out years of evolving work.

Something CodeWarrior mentioned on IRC was the fact that EWL had been rathe=
r
quiet for a while until ETK hit CVS, so the competition must have sparked
the activity. This is wrong, it was just coincidence. Dan and I have been
discussing changes to the tree API for about 3 or 4 months, and I had been
working on an evas object cache. We finally nailed down a solution we think
will give the advantages of an MVC style tree, but maintain more flexibilit=
y
than most implementations. This decision also put the object cache on hold
(which I had just begun to merge) because it will serve some of that
functionality as well as provide additional savings in memory and improved
speed. This change also finalized something I've been considering for a
couple years but never had enough reason to make the change, moving all the
constructors to accept zero arguments. With all of that coming together at
once, there was a flurry of CVS activity implementing the changes we've bee=
n
discussing.

I'm sure I forgot something, but that gets most of my
arguments/excuses/reasons out there for people to pick apart. If you have a
response, please keep it on the list instead of private mail or IRC so we
can at least have an archive of the conversation leading up to any decision
being made.

Thanks,
Nathan

------=_Part_34032_24762217.1128586819684
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/5/05, <b class=3D"gmail_sendername">Brian Mattern</b> &lt;<a href=3D"=
mailto:bmattern@mail.utexas.edu";>bmattern@mail.utexas.edu</a>&gt; wrote:<br=
>
<div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(=
204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Today on IRC=
, there was a rather heated discussion about why ETK was<br>written whether=
 or not EWL should
<br>be scrapped. I'll try to sort through the emotion...<br>(NB: neither Rb=
dPngn nor MoOm, the two lead devs of EWL &amp; ETK<br>respectively were pre=
sent for this discus<br>sion).<br><br>What follows is _my_ take on the two =
camps views.
</blockquote><div><br>
Nice job, I saw a little bit of the conversation, and you've done a
nice job of summarizing without the more insulting portions. Apologies
if this response is incomplete or jumps around, it's been a long day
and I'm running on little sleep this week.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">First, =
the ETK perspective:<br><br>1) EWL just doesn't FEEL right. Meaning: When y=
ou open up an EWL
<br>application
(e.g. e_util_eapp_edit), things don't respond the way one would expect.
Resizing is often buggy, cursors / highlighting in text fields is
strange, etc.</blockquote><div><br>
There are definitely some issues here but I think they've improved
considerably over the last year. There are examples of some fairly
complex layout being done successfully in the test app now as well as a
filemanager written by chaos. The filedialog in particular is packed
pretty nicely, along with the theme test which shows off some of the
theming features EWL incorporates.<br>
<br>
I think we can be cut some slack on the text fields as they were
completely reworked this summer and are fairly complex. They do a
reasonable job towards handling multiline text manipulation with
textblock, which is not an easy thing to do, as CodeWarrior should
know. We do need some auto-scrolling code added, but I've written that
code enough times (Epplets, and a few versions of EWL's text handlers)
that I'd rather not do it again.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2) It w=
ould take longer to learn the EWL internals to be able to<br>meaningfully c=
ontribute than it would to simply start afresh.
</blockquote><div><br>
I'm sorry, but this is a pretty ridiculous argument (I know you're not
the one making it rephorm). Let's take a look at the code to see how
things stack up. We have EWL which weighs in at 38002 lines of code
(30987 removing blank lines), and ETK is 15275 lines of code (12985 w/o
blank lines). This includes comments, such as doxygen docs, for both
projects.<br>
<br>
There are more widgets in EWL, so to be fair I'm going to try and limit
the comparison to the equivalent feature set as best I can. EWL breaks
down as follows.<br>
<br>
Basic building blocks:<br>
&nbsp;&nbsp;&nbsp;&nbsp; 337 Ewl.h<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 49 ewl_private.h<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 70 ewl_macros.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 347 ewl_enums.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 650 ewl_events.c<br>
&nbsp;&nbsp;&nbsp;&nbsp; 166 ewl_events.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 461 ewl_config.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 49 ewl_config.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 896 ewl_misc.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 50 ewl_misc.h<br>
&nbsp;&nbsp;&nbsp; 1539 ewl_object.c<br>
&nbsp;&nbsp;&nbsp;&nbsp; 335 ewl_object.h<br>
&nbsp;&nbsp;&nbsp; 1681 ewl_widget.c<br>
&nbsp;&nbsp;&nbsp;&nbsp; 277 ewl_widget.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 602 ewl_theme.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 52 ewl_theme.h<br>
&nbsp;&nbsp;&nbsp; 1103 ewl_container.c<br>
&nbsp;&nbsp;&nbsp;&nbsp; 165 ewl_container.h<br>
Total: 8829 lines of code (7345 no blank lines)<br>
<br>
This is all the code you would need to really understand in order to
make fundamental changes to the way EWL works. Most of which is pretty
self explanatory, heavily commented and the function names make it
fairly obvious what's going to happen in that function.<br>
<br>
Now let's throw in some widgets that will bring us up to par with ETK funct=
ionality.<br>
&nbsp;&nbsp;&nbsp;&nbsp; 938 ewl_box.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 77 ewl_box.h<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 97 ewl_button.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 51 ewl_button.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 135 ewl_check.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 59 ewl_check.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 130 ewl_checkbutton.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 77 ewl_checkbutton.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 143 ewl_radiobutton.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 72 ewl_radiobutton.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 135 ewl_label.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 51 ewl_label.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 620 ewl_entry.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 62 ewl_entry.h<br>
&nbsp;&nbsp;&nbsp; 1027 ewl_tree.c<br>
&nbsp;&nbsp;&nbsp;&nbsp; 138 ewl_tree.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 128 ewl_colorpicker.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 41 ewl_colorpicker.h<br>
&nbsp;&nbsp;&nbsp;&nbsp; 695 ewl_spectrum.c<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 89 ewl_spectrum.h<br>
</div>Total: 4765 lines of code (3848 no blank lines)<br>
<br>
That gives a grand total of 13594 lines of code (11193 no blank lines).<br>
<br>
So getting back to my original point. The argument being made is that
it's easier to design and write 12985 lines of code and documentation
spread across 70 files than it is to read and understand 11193 lines of
code and documentation? You don't even have to understand the whole
package at once, its split into small, name-spaced files that can be
traced through while you're debugging or just following a specific code
path. Notice a box layout bug? Look at ewl_box.c and find the configure
callback, amazingly it's called ewl_box_configure_cb <br>
<br>
There is also the fact that we now have 1792 more lines of code with
FEWER features and accompanying documentation, and I would be willing
to bet that EWL has just as high or higher comment/code ratio at least
in this set of files. Just as an example, take ewl_text.c which is 3664
non-blank lines. This is functionality that allows for multi-format,
multi-line text to be used in a widget. I only included it in the total
since it's used by ewl_entry.c, but if we had an entry with the same
functionality as the ETK one, we could just use label and eliminate
this file completely. That now makes EWL 5456 fewer non-blank lines
than ETK for similar functionality, and I would contend there is still
more functionality in EWL, theming, configuration, etc.<br>
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3) EWL was de=
signed for Ebits and the original incarnations of Evas and<br>Ecore. The ma=
ny moves to newer
<br>libraries (Edje, modern Evas/Ecore), although commendable, may have<br>=
introduced a number of bugs.</blockquote><div><br>
Again, this doesn't make sense as an argument for a flawed design. Look at =
the logic here:<br>
IF<br>
&nbsp;&nbsp; A =3D EWL was started during Ebits, Evas1 and Ecore1 (not to m=
ention Etox 1, 2, 3..n)<br>
&nbsp;&nbsp; B =3D EWL was ported through all of these library changes<br>
&nbsp;&nbsp; C =3D bugs can occur during a change in code<br>
THEN<br>
&nbsp;&nbsp; D =3D EWL is buggy by design and it's easier to rewrite than f=
ix it<br>
<br>
Do we not see the major logic gap here? Did anyone bother to ask how
much the code changed with those ports? Would you be surprised if I
said that each of those ports involved changing about 100 lines of
code? All of these ports improved the code because the basis it was
built on was more solid and gave us a chance to learn where code
duplication crept in and refactor it.<br>
<br>
Currently, EWL has 193 references to Evas functions and 31 references
to Edje calls. If for some reason there was another Evas rewrite, or a
better canvas or Edje-like lib came around that worked on a somewhat
similar model, EWL could be ported fairly easily. In fact, we could
split out these points into theme engine hooks and drawing methods if
we really saw a good need to support more than Evas and Edje (plus
renaming a few internal functions).<br>
<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> From t=
he EWL camp:<br><br>1) The issues raised with EWL are issues with specific =
widgets, that
<br>have little to do with the fundamental design.</blockquote><div><br>
There were at least 2 cases of discussions on IRC that went something to th=
e effect of:<br>
<br>
&lt;MoOm|CodeWarrior&gt; EWL needs to be rewritten<br>
&lt;RbdPngn|dj2&gt; why?<br>
&lt;MoOm|CodeWarrior&gt; because widget foo does bar, and it shouldn't<br>
<br>
Next day a 2-5 line commit goes in fixing the case of widget foo doing
bar. This is not going to be the case for every issue of course, but it
certainly points to a tendancy on their part to prefer a rewrite over
actually looking for the bug fix.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2) By s=
tarting over, we lose the collective knowledge that is in EWL.<br><br>3) Cu=
rrent EWL development has focused on moving to new API's
<br>(textblock2 e.g.) and optimizing low leve<br>l performance (object cach=
e, etc). The display bugs with the individual<br>widgets, although more not=
iceable to the end user, are less important at the moment.</blockquote>
<div><br>
The object cache work has been very important (even though most of it
has not been merged yet) as it lead to the discovery of other places we
could save memory and widget setup. I would say 3x speedup loading
large directories would qualify as noticeable to the end user. Most of
the layout issues I've seen are the result of some confusion on the
fill policies. I believe the biggest issue is from one or two of the
containers rebuilding their preferred size in ways they shouldn't.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, now=
 we find ourselves facing a difficult point. Very few of us have<br>put for=
th any effort to learn EWLs internals, and thus, judge it based on the feel=
 of an ewl
<br>application. Ostensibly small issues with<br>packing box layout and tex=
t box cursors (and the default theme, which I<br>spent all of an hour on on=
e weekend a few years ago...) make it feel unprofessional.</blockquote>
<div><br>
You're right about the looks, I've changed the default theme to the e17
for now to give it a better match to the default window manager look. I
don't know how many times I can say it, but WE NEED HELP THEMING! I am
decent with basic graphics, but given the choice between working on
code and working on the theme, the code always wins. A lot of the
default theme is just hacks I put in place so I could see the results
of the code. The e17 theme is at least better than that.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It seem=
s as though no one who proposed a rewrite had taken the time to<br>truly le=
arn EWL's internals and
<br>point out the design flaws that warranted a complete rewrite. But, on<b=
r>the
same token, if the plethora of layout issues are really in the higher
level widgets, why have theynot been fixed over all these years?</blockquot=
e><div><br>
Good question, and there only one answer I can give you: it's my fault.
The base of EWL has been changing and evolving, making it very
difficult to have a stable API to write higher level widgets on top of
and to debug some of the issues with lower level widgets. It has
stabilized a fair amount over the last year which has allowed us to
work out more of the layout issues. There has been a ton of work put
into increasing code re-use as much as I can and that has impacted
assumptions that other programmers can make as well as made debugging
more difficult for some cases.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I can't=
 answer, as I also have little idea about the inner workings of EWL.<br>How=
ever, I do think that IF a rewrite IS necessary, we should discuss
<br>the reasons openly, and not slap long time developers in the face with =
a project that completely supplants their baby.</blockquote><div><br>
The project aspect I really don't care that much about. They're welcome
to do their own toolkit project, there are plenty of them out there and
it's a good learning experience, but the fact that their motivations
seem so misguided and that they have been attacking work that they
admit to knowing little about, that bothers me a lot. Yes, EWL is my
&quot;baby&quot; but I'm very open to suggestions on how to improve it. Thi=
s is
why I've asked MoOm and CodeWarrior to PLEASE (yes, I'm asking again)
point out what the design issues truly are if they see some. Then we
can do an evaluation to determine if the issues are such fundamental
flaws that changing the current code base doesn't make sense.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, I'm=
 holding off judgement. I agree that from a users perspective,<br>EWL leave=
s a lot to be desired. But, I've yet to be convinced that this is due to an=
y fundamental design
<br>flaw
in EWL that warrant a total rewrite. (The majority of the visible
issues seem to be h/vbox layout problems to me -- but again, I don't
know enough to really say).<br>
</blockquote><blockquote class=3D"gmail_quote" style=3D"border-left: 1px so=
lid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Okay=
. Enough of my rambling. I just want to get this out there so we can<br>sta=
rt some real discussion and
<br>make a real decision, that even though painful to one side or the other=
<br>is at least explained and justified...</blockquote><div><br>
Thanks rephorm, I appreciate the fact that you at least want some solid rea=
sons before throwing out years of evolving work.<br>
<br>
Something CodeWarrior mentioned on IRC was the fact that EWL had been
rather quiet for a while until ETK hit CVS, so the competition must
have sparked the activity. This is wrong, it was just coincidence. Dan
and I have been discussing changes to the tree API for about 3 or 4
months, and I had been working on an evas object cache. We finally
nailed down a solution we think will give the advantages of an MVC
style tree, but maintain more flexibility than most implementations.
This decision also put the object cache on hold (which I had just begun
to merge) because it will serve some of that functionality as well as
provide additional savings in memory and improved speed. This change
also finalized something I've been considering for a couple years but
never had enough reason to make the change, moving all the constructors
to accept zero arguments. With all of that coming together at once,
there was a flurry of CVS activity implementing the changes we've been
discussing.<br>
<br>
I'm sure I forgot something, but that gets most of my
arguments/excuses/reasons out there for people to pick apart. If you
have a response, please keep it on the list instead of private mail or
IRC so we can at least have an archive of the conversation leading up
to any decision being made.<br>
<br>
Thanks,<br>
Nathan<br>
</div><br></div>

------=_Part_34032_24762217.1128586819684--