dan sinclair wrote:
dan sinclair wrote:
ecore_config -c $DB -k /entrance/daemon/attempts -i 5
I submitted a patch earlier that changes build_config.sh.in..
Why did you remove the previous functionality? Why switch from an obvious set
to a fairly non-obvious -k? Whats wrong with str and int etc.
-k for key
-i for int, -s for string, etc.
I don't think that's very unclear..
But why remove the previous functionality which worked fine. It just caused any
current ecore_config script to break.
that would mean a mess of an options parser..
using hard-coded option sequence like the old code did is not a good
thing. using getopt like this, all options can be specified in any order..
I don't think keeping the old syntax around for compatability with
random scripts is a valid concern.. e17 is, after all unstable..
imo, keeping the old syntax parallell to the new is plain silly :)
only further change I've considered is allowing long options, so people
can use --key, --int, --string etc. if they want to -- and I might still
do that patch up..
I believe the website warns that binary compatability will change during
development, so why should cli interfaces be forced be stable?
I did grep through the e17 cvs tree for ecore_config, and entrance was
the only one I found that used it -- and I did offer a patch for that
one before ecore_config was changed.. it was just missed in checkin ;)
Cheers,
--
Morten
:wq
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
