Re: [E-devel] Tiling module for e17
Hi Will, * [18.04.08 00:10]: The first time I loaded this module, E segfaulted. It loaded successfully the next time, though. However, since unloading it I am unable to load the module again - E segfaults on every attempt. I am attaching a backtrace from gdb. Did you load this module before? I've seen this before when already having a configurationfile. Thanks to your backtrace, I've fixed the problem (I think, please test and confirm). Please use git pull to get the bugfix, re-compile and test again. Best regards, Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: Re: R: checking a part's type?
All ELFs are written in this way, without error checking and reporting, i think it's for performance reason and I like it :) We can simply modify the function to return 1 on success or 0 on error *poker face* I see you rational, well measured idea and raise you a loony wiki article: http://wiki.enlightenment.org/index.php/Edje_Interface_Specification In all seriousness if there is love for my idea I commit to implement it. If there isn't, I will be more than happy with Dave's solution. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: Re: R: checking a part's type?
On Fri, Apr 18, 2008 at 2:05 PM, andres [EMAIL PROTECTED] wrote: All ELFs are written in this way, without error checking and reporting, i think it's for performance reason and I like it :) We can simply modify the function to return 1 on success or 0 on error *poker face* I see you rational, well measured idea and raise you a loony wiki article: http://wiki.enlightenment.org/index.php/Edje_Interface_Specification In all seriousness if there is love for my idea I commit to implement it. If there isn't, I will be more than happy with Dave's solution. Their is. It will be a real win if we can just check if an Edje_Object really provide all the needed stuff. We could even improve it as some type of declaration inside the EDC like the html DOCTYPE (In case we want to check during theme creation). So I am definitevely for number 2 (A parser + compiler and welcome .edt inside Edje). It's sound really like a good idea to me. -- Cedric BAIL - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Tiling module for e17
Michael Stapelberg wrote: Hi Will, * [18.04.08 00:10]: The first time I loaded this module, E segfaulted. It loaded successfully the next time, though. However, since unloading it I am unable to load the module again - E segfaults on every attempt. I am attaching a backtrace from gdb. Did you load this module before? I've seen this before when already having a configurationfile. Thanks to your backtrace, I've fixed the problem (I think, please test and confirm). Please use git pull to get the bugfix, re-compile and test again. Best regards, Michael Yes, I had loaded and configured it before. Removing the old configuration file allowed me to load the module again. After updating, I am able to load/unload Tiling without any issue. I think I could really get used to this thing. I do have one feature request - I'd like to be able to resize all of the windows, not just the Left Main one. Not independently, but if I could drag the borders between the right-hand windows to adjust the amount of real estate given to each that would be fantastic. Thanks, Will signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] R: Re: Tiling module for e17
- Will Keaney [EMAIL PROTECTED] ha scritto: Michael Stapelberg wrote: Hi Will, * [18.04.08 00:10]: The first time I loaded this module, E segfaulted. It loaded successfully the next time, though. However, since unloading it I am unable to load the module again - E segfaults on every attempt. I am attaching a backtrace from gdb. Did you load this module before? I've seen this before when already having a configurationfile. Thanks to your backtrace, I've fixed the problem (I think, please test and confirm). Please use git pull to get the bugfix, re-compile and test again. Best regards, Michael Yes, I had loaded and configured it before. Removing the old configuration file allowed me to load the module again. After updating, I am able to load/unload Tiling without any issue. I think I could really get used to this thing. I do have one feature request - I'd like to be able to resize all of the windows, not just the Left Main one. Not independently, but if I could drag the borders between the right-hand windows to adjust the amount of real estate given to each that would be fantastic. Also my vote goes to this feature request :) Dave Thanks, Will - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ 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-04-18 07:09:21 -0700
Build log for Enlightenment DR 0.17 on 2008-04-18 07:09:21 -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 the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
This is the kind of thing that makes 'chaining' of arbitrary filters a problem unless very strict semantic rules are followed, and an api used which is able to naturally represent those rules. I'll continue this a bit later, but please do jump in with comments or whatnot if you see fit. In order to get a filter api that provides an un-ambiguous, intuitive interpretation for things, we thus need to separate this from the existing 'clipping' api - even if the 'filters' one might be similar, it still really needs to be separate (it'll also allow for greater flexibility if desired). One also really needs to make sure that the 'filters' are typed sufficiently so that it's clear that one's dealing with filters that modify a given object type, or that modify 'surfaces', etc. (of course one can consider rendering an object as a kind of filter on surfaces, with the obj to be rendered to the surface as providing part of the data that defines such a surface filter). Without that, we have the general kind of ambiguity faced with certain common filter notions like geometric transforms or coloring, where one has to decide somehow whether to interpret the effect of the filter as acting on a buffer-surface rendering of the object, or otherwise.. and this is not something unique to smart-objs. For example, in something like transf blur transf polygon the first applied transform could well be interpreted as acting on vertex data, but the last applied one would likely need to be done on surface data - ie. transform a buffer surface that holds the result of blurring a rendered poly (until someone comes up with vertex data for blurry-polygons). Consider implementing the general case of this kind of thing, with arbitrary chains, with loadable filters, with any object... unless you have strict typing mechanisms and composition rules. So long as we maintain strict typing of filters, and semantic rules for filter composition, we have few problems.. otherwise, one has to be more careful in order to resolve possible ambiguities. And as soon as one starts to allow for general/loadable kinds of filters, then one really *has* to have strict typing notions. Whether it's just restricting things to abstract geometric transforms and surface (ie. image) effects, or something more general, one needs to know exactly what one is working with.. a vague 'filters for evas objects.. We can do anything!' idea is just going to lead to an absurd mess. So, what kind of api should be provided for 'filters for evas objects'? And how can general/loadable such filters be defined and obtained? Gustavo has given one possible suggestion (still needs the issue of general/loadable ones addressed, and may want to replace the 'set' with an 'add', or even an 'append/pre-pend' and others). Does anyone else have another? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EFL error handling (was: checking a part's type?)
We could put checks like this in edje_object_part_swallow. But I can't help to think was programmed to work this way for a reason I ignore. All ELFs are written in this way, without error checking and reporting, i think it's for performance reason and I like it :) I sincerely hope that this was an ironic statement. The complete lack of error handling in the EFL (well, apart from image loading) is dooming like the sword of damocles. I'm afraid as EFL gets more popular this will be a _major_ hindrance for professional adoption and I'd really like us to revisit this before it's too late (read: stable APIs). :M: -- Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: Re: R: checking a part's type?
EAPI unsigned char ***
edje_object_part_swallow(Evas_Object *obj, const char *part, Evas_Object
*obj_swallow) {
Edje *ed;
Edje_Real_Part *rp;
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return 0; *
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return 0; **
if (rp-part-type != EDJE_PART_TYPE_SWALLOW) return 0; ***
_edje_real_part_swallow(rp, obj_swallow);
return 1; **
}
then you can use:
if (!edje_object_part_swallow(...))
printf(ERROR);
It's not a 100% safe check but I think it fit your need.
Dave
After I was talked into my senses at the IRC channel, I decided to drop the
enforced-theme-spec-file. Then I began to browse through the Edje api to see
where it could use a little more verbosity. Only edje_object_part_text_set()
is in the same situation.
So while having edje_object_part_swallow() (or text_set) return something is
a good idea, it does not tell the application developer what actually went
wrong. Implementing an Error system in the same manner than
edje_object_file_set seems like an overkill to me.
Thats why I think a function to check the part type is a better approach to
this problem. This way applications can be more verbose about the reasons for
failure, easing theme development.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: Re: R: checking a part's type?
andres wrote:
EAPI unsigned char ***
edje_object_part_swallow(Evas_Object *obj, const char *part, Evas_Object
*obj_swallow) {
Edje *ed;
Edje_Real_Part *rp;
ed = _edje_fetch(obj);
if ((!ed) || (!part)) return 0; *
rp = _edje_real_part_recursive_get(ed, (char *)part);
if (!rp) return 0; **
if (rp-part-type != EDJE_PART_TYPE_SWALLOW) return 0; ***
_edje_real_part_swallow(rp, obj_swallow);
return 1; **
}
then you can use:
if (!edje_object_part_swallow(...))
printf(ERROR);
It's not a 100% safe check but I think it fit your need.
Dave
After I was talked into my senses at the IRC channel, I decided to drop the
enforced-theme-spec-file. Then I began to browse through the Edje api to see
where it could use a little more verbosity. Only edje_object_part_text_set()
is in the same situation.
You will probably find several functions in EFL that are in this same
situation.
So while having edje_object_part_swallow() (or text_set) return something
is
a good idea, it does not tell the application developer what actually went
wrong.
Well, with a little digging, and some EFL knowledge they can find out
what went wrong :)
Implementing an Error system in the same manner than
edje_object_file_set seems like an overkill to me.
Yea
Thats why I think a function to check the part type is a better approach to
this problem. This way applications can be more verbose about the reasons for
failure, easing theme development.
I see no harm in adding an API function to check part type. Certainly
less overhead than having a spec-file type system.
dh
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL error handling
'Mickey' wrote: We could put checks like this in edje_object_part_swallow. But I can't help to think was programmed to work this way for a reason I ignore. All ELFs are written in this way, without error checking and reporting, i think it's for performance reason and I like it :) I sincerely hope that this was an ironic statement. The complete lack of error handling in the EFL (well, apart from image loading) is dooming like the sword of damocles. I'm afraid as EFL gets more popular this will be a _major_ hindrance for professional adoption and I'd really like us to revisit this before it's too late (read: stable APIs). That's not entirely accurate. There's quite a bit of error checking in many of the efl, though there could certainly be much more. But there's little or no error-reporting (even the image loading stuff isn't actually correctly enabled.. at least it wasn't some time back, haven't checked recently). In evas for example, most things will simply fail silently in that a default state is used (eg. if image loading fails, an opaque white image is used). Whether further error-reporting, or at least some return state of fail/success is desirable... - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
