-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 17 Mar 2008 15:07:37 +0100
Massimiliano Calamelli [EMAIL PROTECTED] wrote:
Might I suggest exporting the efreet xml parser and use it instead? Does
anyone object? Using strstr to parse xml isn't very nice.
Sebastian
On my side i
Hello everyone, any news on the EMU / Generic scriptable Menu module for
Enlightenment?
Thanks for the attention :)
greetings to all,
Luca
2008/3/14, The DarkMaster [EMAIL PROTECTED]:
@Christopher: if you wish to help then thank you very much, there's time
until the next release of Ubuntu
Build log for Enlightenment DR 0.17 on 2008-03-19 07:09:25 -0700
Build logs are available at http://download.enlightenment.org/tests/logs
Packages that failed to build:
ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log
engage
Hello everyone,
I've been responsible for the CVS commits regarding Debian packaging
since about two years. The PkgE Debian Team
(http://wiki.debian.org/PkgE) is about to upload or already uploading
some EFL packages to Debian experimental. Would there be any
objections if I merge their changes
On Mar 19, 2008, at 8:36 AM, Falko Schmidt wrote:
Hello everyone,
I've been responsible for the CVS commits regarding Debian packaging
since about two years. The PkgE Debian Team
(http://wiki.debian.org/PkgE) is about to upload or already uploading
some EFL packages to Debian experimental.
Sadly, I have not even had time to get started on this yet :(
devilhorns
The DarkMaster wrote:
Hello everyone, any news on the EMU / Generic scriptable Menu module for
Enlightenment?
Thanks for the attention :)
greetings to all,
Luca
2008/3/14, The DarkMaster [EMAIL PROTECTED]:
Hi Falko,
On Wed, 2008-03-19 at 16:36 +0100, Falko Schmidt wrote:
The PkgE Debian Team (http://wiki.debian.org/PkgE) is about to upload
or already uploading some EFL packages to Debian experimental.
I'm a Member of the Pkg-E team. We are currently working on getting
everything needed for e17
Hi Jan,
On Wed, Mar 19, 2008 at 6:57 PM, Jan Luebbe [EMAIL PROTECTED] wrote:
Hi Falko,
On Wed, 2008-03-19 at 16:36 +0100, Falko Schmidt wrote:
The PkgE Debian Team (http://wiki.debian.org/PkgE) is about to upload
or already uploading some EFL packages to Debian experimental.
I'm a
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the container code and allow for
more code re-use
Massimiliano wrote:
Might I suggest exporting the efreet xml parser and use it
instead? Does anyone object? Using strstr to parse xml isn't
very nice.
Sebastian
On my side i don't have any preference, i initially wrote my
parser 'cause i've to parse a very small
Jan Luebbe [EMAIL PROTECTED] writes:
The changes would include a much better (and Debian policy compliant)
packaging although I would stick to the one-package-per-module method
(as it can be found in evas, for example).
We are grouping the modules together if they have similar runtime
Jose Gonzalez wrote:
Massimiliano wrote:
Might I suggest exporting the efreet xml parser and use it
instead? Does anyone object? Using strstr to parse xml isn't
very nice.
Sebastian
On my side i don't have any preference, i initially wrote my
parser
I'm assuming that they'd love some performance related patches. Writing
something from scratch isn't a good response to a performance issue
unless there is some fundamental reason you can't make it faster/better.
dan
Dale Anderson wrote:
Libxml2 doesn't exactly provide stellar parsing
Dan wrote:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the container code and allow
for
I can't say that I've followed what this is about.. but if
it's something like wether e should have a good xml parser/api
vs. everyone who needs something like that having to write their
own... then I'd say it may be time for e to stop 'poo-poo-ing'
xml (mostly an excuse to
dan sinclair schrieb:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the container code and allow for
Jose Gonzalez wrote:
Dan wrote:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the
Peter Wehrfritz wrote:
dan sinclair schrieb:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the
True, although alot could be said for alot of other abstraction type
libraries in other projects, libxml2 has been around a long time and
having previously read the history on the project an assload of time was
spent on optimising the parsing routine so if things haven't speed up
over the period
I'm not sure I see how using libxml2 wouldn't give you a consistent API
for app development. libxml2 is a consistent API you'd use.
dan
Dale Anderson wrote:
True, although alot could be said for alot of other abstraction type
libraries in other projects, libxml2 has been around a long time
You can do this now with Ewl. The only problem being, everything
is absolute coordinates which is a bit strange for this kind of
widget. If you want to do this, inherit ewl_box, remove configure
event, add your own configure and use ewl_object_place to put the
widgets where you want
On Wed, Mar 19, 2008 at 11:42 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
However you have it (though rel coords would seem best),
if you really want ewl to be a flexible tool for building artistic,
rich apps, then you'll want a natural way to arbitrarily position
child *widgets* - not
Jose Gonzalez wrote:
You can do this now with Ewl. The only problem being, everything
is absolute coordinates which is a bit strange for this kind of
widget. If you want to do this, inherit ewl_box, remove configure
event, add your own configure and use ewl_object_place to put the
However you have it (though rel coords would seem best),
if you really want ewl to be a flexible tool for building
artistic, rich apps, then you'll want a natural way to
arbitrarily position child *widgets* - not just evas objects..
and to allow for custom kinds of child widget
24 matches
Mail list logo
