I'm going to weigh in on this one a little bit. My apologies if I come off
a little stronger than the previous objections did -- hopefully everyone
can see this matter from a rational viewpoint as I observe it. I really do
not get the point of this effort either, even after the explanation. How
is it that we have *three* different widget toolkit implementations in
CVS, in spite of our shortage of human resources in this project? It is a
massive waste of effort and a major step backwards, in my humble opinion.
We've been working on this for over three years and we still don't have a
decent toolkit to show for it -- and our answer to it is fragmentation?
I really appreciate the amount of work you've done Simon, and I respect
your contributions to this project. But I think this should be killed. And
eblocks too. If there are things in Etk that are implemented better than
in EWL, then if necessary kill the corresponding EWL widget and rewrite it
the better way. There's nothing in EWL that cannot be fixed, even if it
requires major, API-breaking, structure-changing fixes. It's still better
than fragmenting efforts and somehow hoping everything will magically work
together sometime in the distant future. Having two, nay three, widget
toolkits competing in the *same* CVS repository, within the same project,
for a limited number of human resources *is* bad. Very bad. I just don't
see how this is going to move us forward here.
Let's think rationally, get our priorities right and pull our resources
together in the right direction. We've done a lot of work here and the
rest of the world is beginning to see it and appreciate what we have done.
But we can still do much better, and this is not the way.
Ibukun
> Hi Nathan, Hi Brian,
>
> First, I have to say that I'm sorry for having kept Etk secret and send
it to the CVS without any notification, it was probably the worst way to
proceed.
> Now, the reasons why I have started Etk: as I always said, I wasn't
fully satisfied with ewl because it didn't worked as I expected it to
do. So I tried for a (short, I agree) moment to improve it by making a
patch for the grid container (which didn't solve all the problems, but
the idea of the fix was there), by making a theme (it has never been
finished because there were a lot of widget size/placement problem with
this theme). I also send a list of 4 bugs/incorrect behaviors for the
menu widgets, but they've never been fixed.
>
> Now, that's true that Etk and Ewl are in direct competition, both dev
teams won't give up their job, and the two projects can't blend together
since they are really two different. The only solution I see is that the
two libs will have to coexist, which is not really bad, it could even
become a way to work better/faster (CodeWarrior and I are already
helping each other on eblocks/etk). Some projects will be made with etk,
and other with ewl. The only thing is that it will be definitively
confusing for the user, and will give two different looks to the apps.
For the last point, I think it could be fixed if the themes of Etk and
Ewl become compatible but it may be hard.
>
> About the licence, I'm not against the BSD licence, it's just that Etk
takes a lot of concepts from GTK (hence the name Etk): properties,
signals, resize system and the API. No code has been taken, everything
has been recoded, but I'm not sure it won't cause licence problems
anyway. So for now, it will stay under LGPL until I'm sure there is no
licence problem.
>
> Regards,
> Simon TRENY <MoOm>
>
>
> Brian Mattern a écrit :
>
>>I'm getting a segv on etk_test here (bt below). I have to agree with
Nathan though. I definitely see nothing wrong with implementing your own
toolkit. However, we could probably get ALOT more done if we pooled our
efforts instead of constantly redoing things. I am curious also, as to
what faults EWL has that led you to design and write your own toolkit.
>>
>>There are definitely two main styles of toolkits in E right now. A
traditional, packed toolkit (ewl, etk, eblocks), and an edje + smart
object based toolkit (esmart, various smartobjs in apps/e). I definitely
see these two styles as coexisting nicely, and worth the somewhat
duplicated effort. However, I really fail to see the need for multiple
packed toolkits.
>>
>>Some other little things. Before committing large projects to CVS (even
to proto), send a note to the list explaining what the project is. Also,
in your initial commit, make the message a little more descriptive. So,
instead of "Import of Eczema", say "Import of Eczema, a new application
that cures that obnoxious condition everyone's been mistaking for
dandruff all these years..."
>>
>>As for licensing, you're definitely free to build on our code and slap
whatever the hell license you want on it (we DO use the anarchist
license after all...) BUT, its still a bit rude. And means your library
won't get as much usage by E folk. (MEJ'll give you hell... :):)
>>
>>Anyway, I hope you don't think we're attacking you. Simply looking for
explanations as to why you made the decisions you did.
>>
>>And now, the promised backtrace:
>>
>>Program received signal SIGSEGV, Segmentation fault.
>>[Switching to Thread 16384 (LWP 2440)]
>>0x00002aaaad08a12c in ecore_str_hash (key=0x1) at ecore_value.c:69 69
for (i = 0; k[i] != '\0'; i++) {
>>(gdb) bt
>>#0 0x00002aaaad08a12c in ecore_str_hash (key=0x1) at ecore_value.c:69 #1
0x00002aaaad0840a5 in _ecore_hash_get_node (hash=0x52b4d0, key=0x1) at
ecore_hash.c:458
>>#2 0x00002aaaad08413e in ecore_hash_get (hash=0x1, key=0x0)
>>at ecore_hash.c:361
>>#3 0x00002aaaaabcd23c in etk_type_property_find (type=0x1,
>>name=0x1 <Address 0x1 out of bounds>, property_owner=0x7fffffb9fb78,
property=0x7fffffb9fb80) at etk_type.c:347
>>#4 0x00002aaaaabcd94a in etk_object_properties_set_valist
>>(object=0x52bbf0,
>>first_property=0x0, args=0x7fffffb9fbd0) at etk_object.c:358
>>#5 0x00002aaaaabcdac0 in etk_object_new_valist (object_type=0x52b3a0,
first_property=0x2aaaaabe1e60 "theme_group", args=0x7fffffb9fbd0) at
etk_object.c:111
>>#6 0x00002aaaaabcfef4 in etk_widget_new (widget_type=0x52b3a0,
>>first_property=0x2aaaaabe1e60 "theme_group") at etk_widget.c:212 #7
0x00002aaaaabda178 in etk_button_new_with_label (label=0x40428c
"Button")
>>at etk_button.c:99
>>#8 0x0000000000402206 in main (argc=1, argv=0x0) at etk_test.c:63
>>
>>--
>>rephorm
>>
>>
>>
>>On Sunday 02 October 2005 21:17, Nathan Ingersoll wrote:
>>
>>
>>>MoOm,
>>>
>>>It looks like you've put considerable effort into this already. It
>>> doesn't
>>>bother me that you wanted to write your own toolkit rather than use
EWL, everyone has their own API style and approach to specific
problems. That being said, I am bothered by the fact dj2 and I asked
you numerous times what fundamental design issues in EWL were a problem
for you, and we
>>> never
>>>got a response other than some bug reports on individual widgets and a
patch for the grid widget which did not get applied because you didn't
respond to my questions about breaking equate.
>>>
>>>I took a brief look at etk after seeing the commit, and felt a couple
comments needed to be made. First off, the LGPL license. I don't think
>>> we
>>>have a "rule" but most E projects are BSD+advertising licensed. By
using the LGPL, you've locked that code out of being re-used in any BSD
>>> licensed
>>>portion of the project w/o converting that portion to LGPL as well. You
have also created a theme (incorporating the e17 images w/o
attribution) that we cannot re-use w/o using the LGPL license.
Secondly, it appears you're following the GTK+ API very closely, if you
are happy with that
>>> API
>>>design and the choice of an LGPL license, why not write a backend to
>>> GTK+
>>>rather than write a full library cloning it's API (this question applies
>>> to
>>>CodeWarrior and eblocks too)? I have not looked at it in depth, but the
default theme does not display correctly on OS X (probably a CPP
portability issue), it's a black window with some text.
>>>
>>>On 10/1/05, enlightenment-cvs@lists.sourceforge.net <
>>>
>>>enlightenment-cvs@lists.sourceforge.net> wrote:
>>>
>>>
>>>>Enlightenment CVS committal
>>>>
>>>>Author : moom16
>>>>Project : e17
>>>>Module : proto
>>>>
>>>>Dir : e17/proto/etk/data/themes/default/widgets
>>>>
>>>>
>>>>Added Files:
>>>>button.edc check_button.edc entry.edc radio_button.edc
>>>>scale.edc scrollbar.edc toggle_button.edc tree.edc windows.edc
>>>>
>>>>
>>>>Log Message:
>>>>* Etk first commit
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by:
>>>>Power Architecture Resource Center: Free content, downloads,
>>>> discussions,
>>>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>>_______________________________________________
>>>>enlightenment-cvs mailing list
>>>>enlightenment-cvs@lists.sourceforge.net
>>>>https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
>>>>
>>>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>enlightenment-devel mailing list
>>enlightenment-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
http://xcomputerman.com
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
