Re: [E-devel] [PATCH] more works and fixes for wallpaper fetcher
-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 don't have any preference, i initially wrote my parser > 'cause i've to parse a very small subset of tags, and i rewritten it to > make it better/faster and to have support for media namespace. > But if you think that efreet's parser is better/faster, feel free to > change. > > Thx > > Massimiliano Still waiting for replies? Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH4OPLleGEL56NNP4RAqzRAKDrPUpTR/VDoCAvgel4CxVwGzDEYgCeOivs lqhPyyxZfbtltks2u+cqQLI= =7kwb -END PGP 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
Re: [E-devel] OpenGEU menu module... can anyone help?
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 and even then... if it will be only a > matter of days until a stable version of the module I need to be created > is released, then we can delay the release of the next OpenGEU of some > degrees. After all, I'm feeling really stupid in releasing a new OpenGEU > with only and hardy base as the sole evolution of the distro :( > So, if you start coding something from monday / thusday, I think we could > make it in time :) > > @ David: Thanks for your answer David. As I said, I dunno why it doesn't > work and if icons could be used and placed next to launchers / sub-menus, > then I didn't understand how to handle them because by installing EMU as it > is, no icon is inside the menu so I have no template / suggestion on how > to have them loaded in the menu itself. If you could put your hands on emu > again it would be wonderful, because this menu module we need, basically, > is just emu on steroids (and not so many steroids, just a working version > with icons support :) )! > > Greetings everyone. > - 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] Nightly build log for E17 on 2008-03-19 07:09:25 -0700
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 http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - 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] Debian files in CVS
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 into the Debian files in CVS to make packages compatible to future official Debian packages? It would affect the following packages (for now): ecore e_dbus edje eet efreet embryo evas ewl 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). Furthermore I would remove the now invalid maintainer name and email address ([EMAIL PROTECTED]) and replace it with mine ([EMAIL PROTECTED]) - but of course only if there're no objections. I've attached a sample patch for eet. I also maintain a Debian sid repository, before on edevelop.org, now on debian.alphagemini.org, which includes CVS snapshot builds and more or less reflects the build rules I maintain in CVS. Regards, Falko - 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] Debian files in CVS
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. Would there be any > objections if I merge their changes into the Debian files in CVS to > make packages compatible to future official Debian packages? > It would affect the following packages (for now): > > ecore > e_dbus > edje > eet > efreet > embryo > evas > ewl > > 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). Furthermore I would remove > the now invalid maintainer name and email address > ([EMAIL PROTECTED]) and replace it with mine ([EMAIL PROTECTED]) > - but of course only if there're no objections. > I've attached a sample patch for eet. > > I also maintain a Debian sid repository, before on edevelop.org, now > on debian.alphagemini.org, which includes CVS snapshot builds and more > or less reflects the build rules I maintain in CVS. Go for it. You should also update the wiki and enlightenment.org pages to reflect that you're the package maintainer instead of me. :) -Blake - 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] OpenGEU menu module... can anyone help?
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]>: >> @Christopher: if you wish to help then thank you very much, there's time >> until the next release of Ubuntu and even then... if it will be only a >> matter of days until a stable version of the module I need to be created >> is released, then we can delay the release of the next OpenGEU of some >> degrees. After all, I'm feeling really stupid in releasing a new OpenGEU >> with only and hardy base as the sole evolution of the distro :( >> So, if you start coding something from monday / thusday, I think we could >> make it in time :) >> >> @ David: Thanks for your answer David. As I said, I dunno why it doesn't >> work and if icons could be used and placed next to launchers / sub-menus, >> then I didn't understand how to handle them because by installing EMU as it >> is, no icon is inside the menu so I have no template / suggestion on how >> to have them loaded in the menu itself. If you could put your hands on emu >> again it would be wonderful, because this menu module we need, basically, >> is just emu on steroids (and not so many steroids, just a working version >> with icons support :) )! >> >> Greetings everyone. >> - 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] Debian files in CVS and Pkg-E
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 into experimental. When we are confident that the packaging is sane, we will push them into unstable. My guess is that it will not be in time for the Lenny release. > Would there be any objections if I merge their changes into the Debian > files in CVS to make packages compatible to future official Debian > packages? When doing that, please make sure that the snapshot tarballs do not include a debian/ directory as this makes the workflow for the Pkg-E Team more complicated. > 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 dependencies and the size of the individual module is very small. The different package split will probably make mixing Pkg-E packages and yours difficult. Jan - 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] Debian files in CVS and Pkg-E
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 Member of the Pkg-E team. We are currently working on getting > everything needed for e17 into experimental. When we are confident that > the packaging is sane, we will push them into unstable. > My guess is that it will not be in time for the Lenny release. OK, good to hear that. > > Would there be any objections if I merge their changes into the Debian > > files in CVS to make packages compatible to future official Debian > > packages? > > When doing that, please make sure that the snapshot tarballs do not > include a debian/ directory as this makes the workflow for the Pkg-E > Team more complicated. Sure, no problem. I won't touch anything below debian/ anyway since debian/changelog has been removed from configure.in. > > 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 > dependencies and the size of the individual module is very small. That sounds sane. Maybe I'll adapt some grouping as well then. > The different package split will probably make mixing Pkg-E packages and > yours difficult. You're right, I'll either have to group them as you did or I will have to go through adding a considerable amount of dependencies. I'll look into it. Falko - 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] Ewl widget positioning
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 internally. We would need to convert all containers to a relative layout and modify the theme system to map the coordinates properly. This would cause issues if we do need to place a widget absolutely, as we'd need to walk the parent tree to figure out where we were, but, how often we need to do this I'm not sure. Thoughts? dan - 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] [PATCH] more works and fixes for wallpaper fetcher
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 subset of tags, and > > i rewritten it to make it better/faster and to have support for > > media namespace. But if you think that efreet's parser is better/ > > faster, feel free to change. > > > > Thx > > > > Massimiliano > > Still waiting for replies? > 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 avoid dealing with it) and consider developing some solid support for it - for those that may wish to NOT write their own when they need to use xml. Like it or not, xml is here and not going away any time soon, its use is almost universal - especially across the web, but also locally as well. PS. Wasn't there "exml" supposedly to deal with this? Or is that another lib that has serious flaws or limitations? - 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] [Pkg-e-devel] Debian files in CVS and Pkg-E
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 > dependencies and the size of the individual module is very small. > > The different package split will probably make mixing Pkg-E packages and > yours difficult. So the right solution is to centralize effort, we have Lutin (Albin Tonerre) working for Ubuntu packaging in the pkg-e repository, you're very welcome to join the effort: [EMAIL PROTECTED] is where most discussion is held, but we also have an alioth project/mailing list. Cheers, -- Niv Sardi - 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] [PATCH] more works and fixes for wallpaper fetcher
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 'cause i've to parse a very small subset of tags, and > > > i rewritten it to make it better/faster and to have support for > > > media namespace. But if you think that efreet's parser is better/ > > > faster, feel free to change. > > > > > > Thx > > > > > > Massimiliano > > > > Still waiting for replies? > > > > 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 avoid dealing with it) and consider developing > some solid support for it - for those that may wish to NOT write > their own when they need to use xml. > Like it or not, xml is here and not going away any time soon, > its use is almost universal - especially across the web, but also > locally as well. > > PS. > Wasn't there "exml" supposedly to deal with this? Or is that > another lib that has serious flaws or limitations? > Why write our own when libxml2 works quite well? Seems like needless NIH to me. dan - 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] [PATCH] more works and fixes for wallpaper fetcher
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 performance does it?, > which appears to me a majority of peoples complaints regarding XML use. > > Dale. > > > > dan sinclair wrote: >> 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 'cause i've to parse a very small subset of tags, and >>> > > i rewritten it to make it better/faster and to have support for >>> > > media namespace. But if you think that efreet's parser is better/ >>> > > faster, feel free to change. >>> > > >>> > > Thx >>> > > >>> > > Massimiliano >>> > >>> > Still waiting for replies? >>> > >>> >>> 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 avoid dealing with it) and consider developing >>> some solid support for it - for those that may wish to NOT write >>> their own when they need to use xml. >>> Like it or not, xml is here and not going away any time soon, >>> its use is almost universal - especially across the web, but also >>> locally as well. >>> >>> PS. >>> Wasn't there "exml" supposedly to deal with this? Or is that >>> another lib that has serious flaws or limitations? >>> >>> >> Why write our own when libxml2 works quite well? Seems like needless NIH >> to me. >> >> dan >> >> - >> 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 >> >> > > > - 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] Ewl widget positioning
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 more code re-use internally. > > We would need to convert all containers to a relative layout and > modify the theme system to map the coordinates properly. > > This would cause issues if we do need to place a widget absolutely, > as we'd need to walk the parent tree to figure out where we were, > but, how often we need to do this I'm not sure. > > Thoughts? > dan Don't know myself. But if this would be a useful internal step to get something like a "canvas" container widget in ewl (and etk) which would allow for arbitrary positioning of child widgets, then that would be a great thing indeed. Such a canvas widget would give the toolkits some much needed flexibility - allowing for things like widget/obj animations, custom/arbitrary layout mechanisms much like evas does with smarts (possibly via deriving other widgets from canvas), and a host of other things. Very important for developing "rich" apps. - 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] [PATCH] more works and fixes for wallpaper fetcher
> >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 avoid dealing with it) and consider > > developing some solid support for it - for those that may wish > > to NOT write their own when they need to use xml. > >Like it or not, xml is here and not going away any time soon, > > its use is almost universal - especially across the web, but also > > locally as well. > > > > PS. > >Wasn't there "exml" supposedly to deal with this? Or is that > > another lib that has serious flaws or limitations? > > > > Why write our own when libxml2 works quite well? Seems like needless > NIH to me. I agree. The only thing would be that one may want to have a wrapper lib(s) that expose a certain api which might be more convenient or easier or better fit to whatnot, etc. - 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] Ewl widget positioning
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 > more code re-use internally. > > We would need to convert all containers to a relative layout and modify > the theme system to map the coordinates properly. > > This would cause issues if we do need to place a widget absolutely, as > we'd need to walk the parent tree to figure out where we were, but, how > often we need to do this I'm not sure. > I don't know if we need to place a widget absolutely, but we need at the end to place the edje and evas objects the absolute coordinates. That was my main concern. Peter - 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] Ewl widget positioning
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 container code and allow > > for more code re-use internally. > > > > We would need to convert all containers to a relative layout and > > modify the theme system to map the coordinates properly. > > > > This would cause issues if we do need to place a widget absolutely, > > as we'd need to walk the parent tree to figure out where we were, > > but, how often we need to do this I'm not sure. > > > > Thoughts? > > dan > > Don't know myself. But if this would be a useful internal > step to get something like a "canvas" container widget in ewl (and > etk) which would allow for arbitrary positioning of child widgets, > then that would be a great thing indeed. > Such a canvas widget would give the toolkits some much > needed flexibility - allowing for things like widget/obj animations, > custom/arbitrary layout mechanisms much like evas does with smarts > (possibly via deriving other widgets from canvas), and a host of > other things. Very important for developing "rich" apps. > 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 them. (Or, alternatively, I think this is what ewl_overlay does already but I haven't used the overlay). dan - 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] Ewl widget positioning
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 container code and allow >> for more code re-use internally. >> >> We would need to convert all containers to a relative layout and >> modify the theme system to map the coordinates properly. >> >> This would cause issues if we do need to place a widget absolutely, as >> we'd need to walk the parent tree to figure out where we were, but, >> how often we need to do this I'm not sure. >> > I don't know if we need to place a widget absolutely, but we need at the > end to place the edje and evas objects the absolute coordinates. That > was my main concern. > We could work around that. Parent containers could cache their current absolute positioning which could be used during Evas/Edje placement. Just, all the internal code that takes position parameters would store them based on relative positioning. That make sense? dan - 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] [PATCH] more works and fixes for wallpaper fetcher
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 of the project theres likely a reason, the other benefit is having a consistent API from an app development perspective. Dale. dan sinclair wrote: > 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 performance does it?, >> which appears to me a majority of peoples complaints regarding XML use. >> >> Dale. >> >> >> >> dan sinclair wrote: >>> 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 'cause i've to parse a very small subset of tags, and > > i rewritten it to make it better/faster and to have support for > > media namespace. But if you think that efreet's parser is better/ > > faster, feel free to change. > > > > Thx > > > > Massimiliano > > Still waiting for replies? > 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 avoid dealing with it) and consider developing some solid support for it - for those that may wish to NOT write their own when they need to use xml. Like it or not, xml is here and not going away any time soon, its use is almost universal - especially across the web, but also locally as well. PS. Wasn't there "exml" supposedly to deal with this? Or is that another lib that has serious flaws or limitations? >>> Why write our own when libxml2 works quite well? Seems like needless >>> NIH to me. >>> >>> dan >>> >>> - >>> >>> 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 >>> >>> >> >> >> > - 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] [PATCH] more works and fixes for wallpaper fetcher
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 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 of the project theres likely a reason, the other benefit > is having a consistent API from an app development perspective. > > Dale. > dan sinclair wrote: >> 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 performance does it?, >>> which appears to me a majority of peoples complaints regarding XML use. >>> >>> Dale. >>> >>> >>> >>> dan sinclair wrote: 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 'cause i've to parse a very small subset of tags, and > > > i rewritten it to make it better/faster and to have support for > > > media namespace. But if you think that efreet's parser is better/ > > > faster, feel free to change. > > > > > > Thx > > > > > > Massimiliano > > > > Still waiting for replies? > > > > 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 avoid dealing with it) and consider developing > some solid support for it - for those that may wish to NOT write > their own when they need to use xml. > Like it or not, xml is here and not going away any time soon, > its use is almost universal - especially across the web, but also > locally as well. > > PS. > Wasn't there "exml" supposedly to deal with this? Or is that > another lib that has serious flaws or limitations? > > Why write our own when libxml2 works quite well? Seems like needless NIH to me. dan - 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 >>> >>> > > > - 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] Ewl widget positioning
> 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 them. (Or, alternatively, I think this is > what ewl_overlay does already but I haven't used the overlay). 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 layout mechanisms. One should not have to 'go-out' of the toolkit based widget framework (and into evas say) in order to develop 'rich' apps. It's not enough to have such abilities only with evas objects, or that you can do this and that and then... It has to be a basic feature of the toolkit itself. But those are just my thoughts on it, others might see things differently. - 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] Ewl widget positioning
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 just evas objects.. and to allow for custom > kinds of child widget layout mechanisms. This is currently what the overlay container is for, but it's based on absolute coords. - 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] Ewl widget positioning
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 > > widgets where you want them. (Or, alternatively, I think this is > > what ewl_overlay does already but I haven't used the overlay). > > 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 layout mechanisms. As I said above, I'm talking about ewl widgets here, not evas objects. dan - 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] Ewl widget positioning
> >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 layout mechanisms. > > This is currently what the overlay container is for, but it's > based on absolute coords. Ah, ok.. interesting :) U... let me ask you this, just as a kind of 'academic' question: How natural (or easy/straight- forward) would it be to write something like 'expedite' with ewl - without the engines or performance stuff, or the actual kinds of gfx things.. just the 'demo' like aspect using say images and maybe some other kinds of widgets (buttons, labels, whatever..)? Or something like that anyway.. But no falling back to 'evas'. :) - 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
