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
