Re: [E-devel] Discuss about a network manager
On Mon, 4 Feb 2008 22:56:47 +0100 Stefan Schmidt <[EMAIL PROTECTED]> wrote: > Hello. > > On Mon, 2008-02-04 at 14:46, Atton Jonathan wrote: > > > > I think 2 projects is not a good idea when e17 need more devs ... > > I hope you don't feel like I trying to replace your project. > Personally I don't see any problem if these two things co-exist. It's > about choice. I really think you should continue your work on exalt as > long as it brings fun in your life. (Also I still have to come up with > code before we really can talk about a competition here). > don't worry about that :) Currently I m the only coders on Exalt and it's a lot of jobs. NM have a lot of devs that's why I think the futur is NM and not Exalt. Gos and Elive have choose Exalt because it's the only solution for E17 but they need the best solution. -- Regards, Atton Jonathan <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Use of the 'Requires.private' field in pkg-config files
Hello,
I'd like to suggest that we use the new (as of pkg-config 0.22)
'Requires.private' flag in the .pc files instead of the current 'Requires' flag.
'Requires.private' is a field that basically has the same role as 'Requires'.
However, the dependencies listed in this field are not used when
`pkg-config --libs foobar' is called (only when dynamic linking is done, ie no
--static is specified).
This prevents unneeded recursive linking of the dependencies, like this is
currently the case (eg, everything linked against ecore-file with CURL support
enabled is also linked against curl, which is a maintenance hell and a complete
nonsense, and this is one example out of many).
That means that in our case, Requires.private field can replace Requires
virtually everywhere if the dependencies have no undefined symbols and if they
don't specify anything else than -l/-L flags.
As a quick example of what the benefit would be, I rebuilt the EFL, E, etk and
ewl using Requires.private instead of Requires in their pkg-config files, and
ran objdump -p $foo | grep NEEDED on every {module,shared library,binary} before
and after the change. The results can be found at
http://people.dunnewind.net/lutin/files/efl_links--.diff
The obvious drawback, of course, is that it would break build on every install
where pkg-config 0.22 is not available, which is quite unpleasant, given that
it's only 8-month old. I'm sending this mail for the record, though :)
Cheers,
--
Albin Tonnerre, aka Lutin
signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E CVS: apps/e barbieri
> Modified Files: > e_widget_frametable.c e_widget_frametable.h > > Log Message: > Add const to frametable's label. > Just a minor thought here on all this widgetry stuff... For all of these 'e_widgets', wouldn't it be better to have a consistent interface for 'adding' them to an evas? For example, say of the form: Evas_Object *e_some_widget_type_add(Evas *evas); and then have functions for setting the relevant properties.. Or, as another possibility, say of the form: Evas_Object *e_some_widget_type_add(Evas *evas, void *property_class); where 'property_class' would refer to a type specific struct that would hold the relevant things desired.. (Or some combination of these.. say the simple 'add' with no property arguments, and a function to set the property_class). This would not only allow for a simpler, more consistent methodology, but also make it easier to change or extend the kinds of initializing properties used. In a somewhat different vein: Since these 'widgets' possibly need some set of edje groups to define their 'theme', wouldn't it also be desirable to allow one to be able to specify an edje file that would hold the required theme elements? This would allow for any given widget instance to be separately themed - if desired (I believe both ewl and etk allow for something like that?). BTW, what happenned to Hisham's "eblocks"? Wasn't that a lib similar to these e-widgets stuff? jose. _ Be your own boss. Click here for information on starting your own business. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l5e2pbSxwe17Zn1lfnNkod0YFs2zzs0Ex5FPeIaPJmOX4G8/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e barbieri
On Feb 6, 2008 5:53 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > BTW, what happenned to Hisham's "eblocks"? Wasn't that a lib > similar to these e-widgets stuff? > That was a toy of mine that was written as a proof-of-concept toolkit using pure C# and EFL# (C# bindings). -- Hisham Mardam Bey http://hisham.cc/ +1-514-966-8359 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
