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, [email protected] <
>
> [email protected]> 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
> > [email protected]
> > 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
