[E-devel] [PATCH] External parts in Edje
Hey everyone,
I've attached a patch that implements a new edje part type: EXTERNAL.
The basic idea is as follows:
An application (or library) can implement swallowable widgets that are
keyed by a type name. By implementing a few callbacks and registering
with edje, the app can allow a themer to include a part of this type by
simply doing:
part {
name: "external_part";
type: EXTERNAL;
source: "type_name";
description {
...
params { int: "foo" 10; string: "bar" "str_val"; ... }
}
}
The current callbacks are:
Evas_Object *add(void *data, Evas *e, Evas_Object *parent, const
Eina_List *params)
gets called when edje loads and finds an external part of this type
the parent object is passed in so that it can be sent signals/messages
void signal_emit(void *data, Evas_Object *obj, const char *emission,
const char *source)
probably should be called 'signal_recv' or so, but gets called when
a signal like 'external_part:signal_name' is sent to the parent edj
(like GROUP objects, the part name and colon gets stripped off).
void state_set(void *data, Evas_Object *obj, const Eina_List
*from_params, const Eina_List *to_params, float pos)
called whenever the state changes (including repeatedly while
tweening between states)
use pos to linearly interpolate params between states
I also attached a really basic test program (nothing fancy, left or
right click on the bg to trigger state changes or press 's' to switch
themes) to illustrate the usage.
It would be interesting to register all of elementary's widgets with
edje in this fashion. (We'd still need some way for the theme to specify
which app data should be associated with the widget).
Anyway, before committing this, I'd like to get some feedback on the API
and ideas for how to extend this concept.
Brian
external_test.tar.gz
Description: application/gzip
diff --git a/src/bin/edje_cc_handlers.c b/src/bin/edje_cc_handlers.c
index c68a4e3..2ad00d2 100644
--- a/src/bin/edje_cc_handlers.c
+++ b/src/bin/edje_cc_handlers.c
@@ -129,6 +129,7 @@ static void st_collections_group_parts_part_box_items_item_options(void);
static void st_collections_group_parts_part_table_items_item_position(void);
static void st_collections_group_parts_part_table_items_item_span(void);
+
static void ob_collections_group_parts_part_description(void);
static void st_collections_group_parts_part_description_inherit(void);
static void st_collections_group_parts_part_description_state(void);
@@ -194,6 +195,11 @@ static void st_collections_group_parts_part_description_table_homogeneous(void);
static void st_collections_group_parts_part_description_table_align(void);
static void st_collections_group_parts_part_description_table_padding(void);
+/* external part parameters */
+static void st_collections_group_parts_part_description_params_int(void);
+static void st_collections_group_parts_part_description_params_double(void);
+static void st_collections_group_parts_part_description_params_string(void);
+
static void ob_collections_group_programs_program(void);
static void st_collections_group_programs_program_name(void);
static void st_collections_group_programs_program_signal(void);
@@ -391,6 +397,9 @@ New_Statement_Handler statement_handlers[] =
{"collections.group.parts.part.description.table.homogeneous", st_collections_group_parts_part_description_table_homogeneous},
{"collections.group.parts.part.description.table.align", st_collections_group_parts_part_description_table_align},
{"collections.group.parts.part.description.table.padding", st_collections_group_parts_part_description_table_padding},
+ {"collections.group.parts.part.description.params.int", st_collections_group_parts_part_description_params_int},
+ {"collections.group.parts.part.description.params.double", st_collections_group_parts_part_description_params_double},
+ {"collections.group.parts.part.description.params.string", st_collections_group_parts_part_description_params_string},
{"collections.group.parts.part.description.images.image", st_images_image}, /* dup */
{"collections.group.parts.part.description.font", st_fonts_font}, /* dup */
{"collections.group.parts.part.description.fonts.font", st_fonts_font}, /* dup */
@@ -550,6 +559,7 @@ New_Object_Handler object_handlers[] =
{"collections.group.parts.part.description.gradient.rel2", NULL},
{"collections.group.parts.part.description.box", NULL},
{"collections.group.parts.part.description.table", NULL},
+ {"collections.group.parts.part.description.params", NULL},
{"collections.group.parts.part.description.color_classes", NULL}, /* dup */
{"collections.group.parts.part.description.color_classes.color_class", ob_color_class}, /* dup */
{"collections.group.parts.part.description.program", ob_collections_group_programs_program}, /* dup */
@@ -1651,6 +1661,7 @@ st_collections_group_parts_part_type(void)
"GROUP", E
Re: [E-devel] Elicit
The relevant code is in grab.{h,c}
All you would need to do is implement elicit_grab_region(), which fills
the data pointer (an int array) with the screen data for the region
passed in.
For now, just conditionally compiling the correct implementation should
be enough. No need for modules unless one wants multiple grabbers for a
single OS (e.g. maybe something that grabs the pixels from the
compositor if one if running?)
Brian
Vincent Torri wrote:
>
> Hey,
>
>> For those of you who use elicit (a screen magnifier /color picker), I
>> have a mostly rewritten version in a git repository at:
>> http://github.com/rephorm/elicit/
>>
>> It is still under construction, but most of the functionality is there
>> again, plus a bit more.
>>
>> I have not reimplemented the ruler yet, but you can now right click and
>> drag in the screen shot to select a region there and get information
>> about its width/height (nicer than counting pixels).
>>
>> The README explains what has been implemented so far.
>>
>> Let me know if you have any comments, concerns or criticisms.
>
> i know how to get a screenshot of the entire screen on windows. I've
> not looked deeply at your code, but can you guide me a bit, to know
> which part i should rewrite for a windows port ? I think that, except
> the imlib2 part for the screen capture, everything is already ported
> to windows. Hence, the amount of work should be minimal.
>
> And maybe it would be nice to have maybe some "modules", in order to
> make elicit working on other computers / devices. What do you think ?
>
> Vincent
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Elicit
For those of you who use elicit (a screen magnifier /color picker), I have a mostly rewritten version in a git repository at: http://github.com/rephorm/elicit/ It is still under construction, but most of the functionality is there again, plus a bit more. I have not reimplemented the ruler yet, but you can now right click and drag in the screen shot to select a region there and get information about its width/height (nicer than counting pixels). The README explains what has been implemented so far. Let me know if you have any comments, concerns or criticisms. Take care, Brian P.S. Good work on the EFL over the past two years everyone. Its come along a bit. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] winter theme maintainer
Hey everyone, I recently started a PhD program in physics, and my time for E has dropped to virtually nil. The past years of working on e have been good, but its time for me to move on. There are a few projects that I will no longer be maintaining: Elicit I do less and less graphics work these days, but I know there are a few out there who rely on this little app. So, if anyone wants to work on a fairly small non toolkit efl app, this is in need of a maintainer. Winter E17 Theme I've put up xcf's and the original edc's i have at: http://rephorm.com/files/winter/ Efreet Has other maintainers. E_DBus Do with as you guys please :) E_Phys I'll hand this off to Peter Wehrfritz, as he's expressed interest before. Feel free to change in any way shape or form. Iconbar, Express: Dead or never quite alive. Feel free to stick 'em in the attic somewhere. Esmart_Container Used by a couple of older apps still lying around (including elicit). Hopefully whoever takes on elicit will keep this alive (or move to something based on E_Box or add / finish up containers in edje. Please cc me on any responses, as I don't read the list regularly anymore. Thanks in advance for anyone who decides to take on any of the above projects. Take care! Brian (rephorm) Mattern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] A simple NetworkManager query app
I unfortunately don't have a wireless card on a linux box. So, I just get the 'eth0'. But, it seems to work. One note - calling 'Wireless' methods on 'Wired' objects throws an error. You might want to delay the call until the type is returned (and then only if its wireless). Brian On Sun, Jul 22, 2007 at 08:14:45PM -0400, Ross Vandegrift wrote: > Hey everyone, > > Going with my post of a patch to update e_dbus, here's a simple app > that uses that updated API to query NetworkManager. > > It pulls the list of all interfaces in the system, and prints their > system name, type, and any wireless networks that they know about. > > You obviously need e_dbus with the updates I just posted! > > http://kallisti.us/~ross/enetmgr-0.1.tar.gz > > > -- > Ross Vandegrift > [EMAIL PROTECTED] > > "The good Christian should beware of mathematicians, and all those who > make empty prophecies. The danger already exists that the mathematicians > have made a covenant with the devil to darken the spirit and to confine > man in the bonds of Hell." > --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E_DBus - IPC replacement
I gave this a quick read-through. Haven't had time yet to update
everything, so I can't apply it yet.
A few quick thoughts on the API.
I'd prefer to see a more object oriented API.
I.e. rather than having a single 'RemoteObject' that all calls go
through, have something like:
/org/enlightenment/wm
org.enlightenment.wm.Core
Restart()
Exit()
ListModules(OUT as)
org.enlightenment.wm.System
Suspend()
Hibernate()
Reboot()
Shutdown()
Logout()
LockScreen()
org.enlightenment.wm.Config
Set(IN s, IN v)
Get(IN s, OUT v)
GetMultiple(IN as, OUT a{sv})
/org/enlightenment/wm/module/
org.enlightenment.wm.Module
Load()
Unload()
Enable()
Disable()
org.enlightenment.wm.Config
The names are still debatable, but I prefer having the modules as
separate objects on the bus. E could just create these for all available
modules, and provide a means for a module to fetch its bus object
(allowing it to register additional interfaces if desired).
Additionally, we may want to look into some of the existing specs for
things like power management, and if feasible, implement at least a
subset of them.
For config, i'm not sure how easily we can map dbus types to config
value types (or lookup values by property name). So, we may end up
needing individual get/set methods for each property (as the current ipc
is done).
Anyway, thanks for the initiative here.
Anyone else have ideas on how they'd like a dbus API for e to look?
Brian
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Update e_dbus NetworkManager functions to current API
Can someone commit this for Ross (as long as it compiles)? If not, I'll do it
in a week or so.
Thanks for the help digging up all of nm's api.
Brian
On Sun, Jul 22, 2007 at 08:07:59PM -0400, Ross Vandegrift wrote:
> Hello everyone,
>
> As I mentioned earlier, I've been playing a bit with getting
> NetworkManager support to do good stuff in E. This patch updates
> e_dbus to use the most accurate NM interface that I could find.
>
> The patch adds all the functionality required, but I am too dumb to
> figure out how to get "cvs diff -N" to work like "diff -N" and
> actually include the new file. Instead, I've attached the missing
> file which will need to go into src/lib/nm/ for e_dbus.
>
> Next email will have a simple sample app that gets information about
> network devices from NetworkManager.
>
>
>
> ? src/lib/nm/e_nm_network.c
> Index: src/lib/nm/E_Nm.h
> ===
> RCS file: /var/cvs/e/e17/proto/e_dbus/src/lib/nm/E_Nm.h,v
> retrieving revision 1.1
> diff -u -r1.1 E_Nm.h
> --- src/lib/nm/E_Nm.h 21 Mar 2007 10:31:16 - 1.1
> +++ src/lib/nm/E_Nm.h 23 Jul 2007 00:01:55 -
> @@ -26,4 +26,26 @@
> /* org.freedesktop.NetworkManager api */
> int e_nm_get_devices(E_NM_Context *ctx, E_NM_Callback_Func cb_func, void
> *data);
> int e_nm_sleep(E_NM_Context *ctx, E_NM_Callback_Func cb_func, void *data,
> int do_sleep);
> +
> +
> +/* org.freedesktop.NetworkManager.Device api */
> +int e_nm_device_get_name(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> +int e_nm_device_get_type(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> +int e_nm_device_get_hal_udi(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> +int e_nm_device_get_ip4_address(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> +int e_nm_device_get_link_active(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> +int e_nm_device_wireless_get_strength(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> +int e_nm_device_wireless_get_active_network(E_NM_Context *ctx,
> + const char *device,
> + E_NM_Callback_Func cb_func,
> + void *data);
> +int e_nm_device_wireless_get_networks(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data);
> #endif
> +
> Index: src/lib/nm/Makefile.am
> ===
> RCS file: /var/cvs/e/e17/proto/e_dbus/src/lib/nm/Makefile.am,v
> retrieving revision 1.5
> diff -u -r1.5 Makefile.am
> --- src/lib/nm/Makefile.am22 Mar 2007 07:47:37 - 1.5
> +++ src/lib/nm/Makefile.am23 Jul 2007 00:01:55 -
> @@ -12,6 +12,7 @@
> e_nm.c \
> e_nm_manager.c \
> e_nm_device.c \
> +e_nm_network.c \
> e_nm_util.c
>
>
> Index: src/lib/nm/e_nm_device.c
> ===
> RCS file: /var/cvs/e/e17/proto/e_dbus/src/lib/nm/e_nm_device.c,v
> retrieving revision 1.2
> diff -u -r1.2 e_nm_device.c
> --- src/lib/nm/e_nm_device.c 22 Mar 2007 19:52:59 - 1.2
> +++ src/lib/nm/e_nm_device.c 23 Jul 2007 00:01:55 -
> @@ -1,72 +1,161 @@
> +/*
> + * This file defines functions that query each of the functions provided by
> + * the NetworkManager Device interface.
> + */
> +
> #include "E_Nm.h"
> #include "e_nm_private.h"
> #include
>
> -#define e_nm_device_call_new(path, member)
> dbus_message_new_method_call(E_NM_SERVICE, path, E_NM_INTERFACE_DEVICE,
> member)
> -#define e_nm_device_wired_call_new(path, member)
> dbus_message_new_method_call(E_NM_SERVICE, path, E_NM_INTERFACE_DEVICE_WIRED,
> member)
> -#define e_nm_device_wireless_call_new(path, member)
> dbus_message_new_method_call(E_NM_SERVICE, path,
> E_NM_INTERFACE_DEVICE_WIRELESS, member)
> +/**
> + * Get the system name of a NetworkManager device
> + *
> + * Returns an Ecore_List of dbus object paths for network devices. This list
> is
> + * of const char *, and is freed automatically after the callback returns.
> + *
> + * @param ctx an e_nm context
> + * @param device a NetworkManager device to communicate with
> + * @param cb a callback, used when the method returns (or an error is
> received)
> + * @param data user data to pass to the callback function
> + */
> +int
> +e_nm_device_get_name(E_NM_Context *ctx, const char *device,
> + E_NM_Callback_Func cb_func, void *data)
> +{
> + return e_nm_get_from_device (ctx, device, cb_func, data, "getName",
> +DBUS_TYPE_STRING);
> +}
>
>
> +
Re: [E-devel] E_DBus - IPC replacement
As a heads up, I've got this flagged to look at, but definitely won't have time until i get back from my honeymoon (week from friday). Thanks for taking the initiative on this. Brian On Mon, Jul 23, 2007 at 09:59:03PM +0900, Stafford Horne wrote: > Hi All, > > Thanks for the feedback. I have completed initial development. With the code > available here: > > http://blog.shorne-pla.net/uploads/e17dbus/ > > If anyone would like to review it please let me know. The build system needs > to be cleaned up a bit right now. But the code is all there with an example > module. > > -Stafford > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Wed, Jul 18, 2007 at 12:56:17AM -0300, Gustavo Sverzut Barbieri wrote: > On 7/18/07, Brian Mattern <[EMAIL PROTECTED]> wrote: >> On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: >> > Notice that edje property is no_mouse_grab, because then we can keep >> > compatibility with existent .edj files. >> > >> > I don't like evas_object_mouse_grab_set() very much, it looks like >> > mouse will be immediately grab, which is not the case. But I don't >> > have any better word for that. >> >> > + EAPI void evas_object_mouse_grab_set >> (Evas_Object *obj, Evas_Bool no_mouse_grab); >> > + EAPI Evas_Bool evas_object_mouse_grab_get >> (Evas_Object *obj); >> >> >> Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? >> (or _mouse_auto_grab_) > > it's not that better... other suggestions? > > can_grab_mouse? That makes even less sense. Maybe "grab" isn't a good choice. Really we're picking between two alternate methods of presenting mouse events. So, maybe evas_object_mouse_event_mode_set(obj, EVAS_EVENT_MODE_X) I'm at a loss atm as to what the two names should be though. (Maybe ORIGINAL and RAW... not happy with those...) > > >> Whatever we call it, the second parameter should NOT be no_*. It should >> be TRUE for "grab the mouse", and simply default to TRUE. > > yes, I agree, but how about edje files? Can I rely on people updating > their edje files? Remember that edje files will not be recompiled > since they have not changed, users may issue "make clean" to get it > updated. For edje files, you either need compatibility code (where the version is checked on load and the value is set properly), OR you can just make the edje option 'negative' (it doesn't have to be the same as the c api). However, with the above suggestion for an API, the 'original' mode would just be equal to 0. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: > Notice that edje property is no_mouse_grab, because then we can keep > compatibility with existent .edj files. > > I don't like evas_object_mouse_grab_set() very much, it looks like > mouse will be immediately grab, which is not the case. But I don't > have any better word for that. > + EAPI void evas_object_mouse_grab_set(Evas_Object > *obj, Evas_Bool no_mouse_grab); > + EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object > *obj); Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? (or _mouse_auto_grab_) Whatever we call it, the second parameter should NOT be no_*. It should be TRUE for "grab the mouse", and simply default to TRUE. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new project for e17
On Sun, Jul 15, 2007 at 12:02:41PM -0700, Daniel Patterson wrote: > On Sun, 15 Jul 2007 14:33:08 -0400 > Ross Vandegrift <[EMAIL PROTECTED]> wrote: > > > On Sun, Jul 15, 2007 at 11:15:45AM -0700, Daniel Patterson wrote: > > > Using any Gnome daemon ties in gnome dependencies > > > > Nope. NetworkManager is designed to be agnostic to any particular > > environment. KDE uses it for it's backend as well. From my box: > > > > [EMAIL PROTECTED]:~$ apt-cache depends network-manager > > network-manager > > Depends: > > > > I suppose you might take issue with glib, hal, or dbus, but have fun > > with lots of things at that point... > > > > > > I stand corrected... what I said was based on personal experience with > it a while ago (around a year)... I tried to install it and it pulled in > twenty to thirty dependencies... perhaps something was wrong with it in > its early stages, or it was mistakingly pulling in something it did not > actually need. NetworkManager consists of two independent pieces that communicate using dbus. A desktop agnostic daemon runs and does all the actual interface configuration, etc. A desktop specific application sits on top and provides an interface to switch wireless networks, enter wep keys, indicate that a wired network is available and being used, etc. So, although technically for NM to be *useful* either gnome or kde would need to be installed OR one would need to write an efl based frontend. If you are interested in the latter, the daemon side of the protocol (the org.freedesktop.NetworkManager interface) has been at least partially wrapped by the code in: e17/proto/e_dbus/src/libs/nm. This would be used for the applet to call methods on the daemon. The other half (daemon calling methods on the applet, like, 'give me the wep key for access point X), i sunder the interface 'org.freedesktop.NetworkManagerInfo', and has not been implemented. When I was looking at all this back in March, I believe there were plans to re-work the NetworkManagerInfo api. I'm not sure if that was ever done, or is still being planned. At the time, the existing API was undocumented, and had to be determined through dbus introspection and digging through the daemon / applet code. That said, I do think that utilizing NM is the correct way to move forward with such a 'network configuration' thing. The NM code in e_dbus atm is entirely untested, so feel free to take or leave it as you choose. (The code there at least needs to be moved from E_NM_Callback_Func -> E_DBus_Callback_Func). Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] e_dbus HAL segfaults on early error in cb
On Tue, Jul 10, 2007 at 10:15:41PM +0200, Joel Klinghed wrote: > Hi. > > This little trivial patch stops e_dbus HAL from segfaulting when the > E_HAL_HANDLE_ERROR() trigger in callbacks. > > /Joel Klinghed > Thanks, I'll commit this tonight (unless someone wants to beat me to it). Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e devilhorns
On Tue, Jul 10, 2007 at 07:15:35AM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : devilhorns > Log Message: > Give menu apps dialogs (favs, ibar, etc, etc) ability to move items up/down > in the list. Allows user to "customize" their order in the menus, as per > ManoWarrior feature request. > > Added some API to ilist widget to help with this. iList can now do > append_relative, prepend, and prepend_relative. > Thanks. This had been sorely needed for a while. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Conf dialogs... modules?!
On Sun, Jul 08, 2007 at 01:40:37AM +0300, Hisham Mardam Bey wrote: > On 7/7/07, Luchezar Petkov <[EMAIL PROTECTED]> wrote: > > Raster, why the heck are you doing this? I don't like the idea (and its not > > only me, of course)... At least explain us :-) > > > > This is actually not a very bad idea, its actually a good move towards > refactoring a lot of E's code and making it cleaner (if this continues > with all the non-WM stuff in E that is). > > The only annoyance I can see here is having to load those modules > yourself - which might be a bit of a problem to the clueless new user. I think they're on by default. Its just that there is no code to turn them on for old configs (nor should there be). > > I personally do advocate the idea though. The more important thing is > to continue on doing this. I agree. Pushing functionality into modules has a side effect of forcing the interfaces to be abstracted and (hopefully) cleaner. > E has become a BIG beast with a lot of > features that are not required by a WM. What WM has so much > configuration dialogs? X configs? Includes its own panels, > mini-modules? File manager? > > After thinking about the state of E (the WM / desktop shell first, and > the entire EFL second), I believe that this is exactly what we need. > We need to do this for everything that does not belong to the core WM. > Things need to be moved out of the main code base and refactored. > > I even believe that we need to do this sort of thing for the "desktop" > itself. E draws its own desktop, completely ignoring X's root window. > Ignoring the root window itself is not a problem, but I firmly believe > that we need to move the entire "canvas desktop" idea outside E. Call > it e_desktop or whatever. E, as a WM, should not have to draw this > desktop, handle the clock, battery, ibar, etc. and the rest of the > modules that load and draw on the desktop. By putting this into E, not > only have we made it bigger and slower, we have also made it more > error and crash prone. > > The e_desktop application could, if need be, open up the space for > modules like the ones we currently have. There is no reason for them > to be a part of E itself. Now one would argue that some of those > modules do in fact need access to some of the info that E has (ibox, > drop shadow, pager?) but I am sure that we can find a sane way to do > this stuff as well (I have not given those modules any thought as of > now). > > Another part of E that really needs to move outside its code base is > EFM. EFM is growing and becoming a terrifying beast. Anyone that has > tried to fix something or add something to it knows that (ask me, I > spent two hours understanding its code trying to add a feature the > other day). Not only does EFM have its own process now, it keeps on > growing and growing, and it still has a good way to go. We need to > move EFM outside E and turn it into a standalone proper file manager. > At that point, E can *use* EFM for its file dialog needs, and having > a file manager inside E as an excuse to needing a file selector / > dialog for some internal things (background choosing, theme choosing > etc) will no longer be a valid excuse to code a full fledged file > manager inside E. Much of how the three components (wm, fm, desktop) interact would need to be re-thought. The IPC interfaces would need a LOT of work. That said, the filemanager already does the majority of its work in a helper application. Anyway, I would like to hear from raster about the reasons behind mashing all of this functionality into one monolithic process before giving any more though to how it could be split up. :) > > Another component that should also be removed from E itself (maybe > even completely deleted and replaced with an already existing library, > or appended to that library) is e_thumb. e_thumb has no place inside E > itself. We have Epsilon, a perfectly working library that can work > both in "library mode" and in IPC mode as a service. If Epsilon has > given some of us some trouble then we should fix it and use it instead > of implementing a thumbnailer in E itself. > I never did understand why epsilon was ignored. I know this was brought up at least on IRC years ago. The 'no deps' requirement here just resulted in much of the code in epsilon being rewritten inside e. I'll leave the rest of this email for later (gotta run). rephorm. - End forwarded message - - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cvs developer access for glassy
On Sat, Jul 07, 2007 at 12:29:25PM +0600, Yuri wrote: > Hi guys! > > I spend some time on EngyCAD and get it working on current EFL. > I'd like to put it to e.org CVS, if you don't mind :) > > Here comes my info and cvs pubkey. Welcome back! The attachments don't seem to have made it through, though. If you want, send them directly to me and I'll add you. Brian (rephorm) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Add Edje fill.type
On Fri, Jul 06, 2007 at 03:25:28PM +0200, Cedric BAIL wrote: > Hi, > > This patch add support for a new fill.type argument. Fill.type could be > : > - SCALE : Relative coord in the fill section are relative to the > container > (like without the patch) and it's the default value. > > - TILE : Relative coord are relative to the image size (not anymore to > the > container). This does not impact use of offset in fill section. > > Cedric > I'll try to look at this tomorrow. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Sat, Jun 16, 2007 at 12:18:45PM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : raster > +e_fm_shared.h This file wasn't added. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Sat, Jun 16, 2007 at 12:51:40PM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : raster > Project : e17 > Module : apps/e > > Dir : e17/apps/e/src/bin > > > Modified Files: > e_fm_main.c > > > Log Message: > > > hmm- hal insists on mounting as root, not user. i wonder why. options to > hal's mount method just end up failing. You may need to add yourself to the 'storage' group. Check /etc/dbus-1/system.d/hal.conf to see what sort of premissions are set up in there. Also, your callback *should* get called with the error when it fails (which has a message field that can be sent directly to a dialog iirc). Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 themes, etc.
On Wed, Jun 06, 2007 at 01:27:38PM +0200, muzzle wrote: > I have a laptop with one of those glossy transreflective screen that > becomes a perfect mirror when displaying dark colors. This means that > 90% of the enlightenment themes are useless to me (awesome, but > useless). The only 3 options I have are clearlooks, milky and simply > white. The winter theme is also light. http://rephorm.com/design/winter Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] edje - slight api change
Along with the GROUP part support I committed over the weekend, came a
slight change to edje_object_part_swallow(). This function will now ONLY
operate on SWALLOW parts. If you try to swallow into e.g. a RECT, it
will fail.
Unfortunately, the API currently does not return a status on whether the
swallow succeeded (i.e. the part existed and was of type SWALLOW) or
not. Maybe we can change this later to return 1 on success and 0
otherwise?
There has been at least one report of a broken theme due to this ("empty
menus"). The fix is to simply change any parts that get swallowed into
to the correct type (for e17 themes, they SHOULD all be named
e.swallow.*, so checking a theme for correctness isn't too difficult).
Brian
p.s. for those who don't read the commit list, see
http://cia.vc/stats/project/e/e17/libs/edje/.message/4d31e
for more about GROUP parts
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] WWW!
On Mon, Apr 30, 2007 at 10:27:45PM +0300, Luchezar Petkov wrote: > Jaime Thomas wrote: > > I've written them for Eclair, Elicit, Exhibit, Estickies. Can write for > > others. > > > > jethomas > > > > Ok, send me what you have about Exhibit and Estickies. I'll check those > out. Eclair is officially dead, Elicit, iirc isnt maintained anymore. Incorrect. Elicit is alive and working well. (13 commit emails in march and 5 in may). Please check before spreading misinformation. :) Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 + dbus = hard requirement
Right now the ecore dbus requirement is 'hard', but that has no compile time dependencies. (It only depends runtime on dbus being installed). If you don't have dbus installed, it will simply not be able to connect to the bus, and ignore those sections of code. If we ever move to e_dbus, THAT depends compile time on libdbus, and so we'd need to make all the code in e optionally compile. However, I'm not sure if that is even really planned. In short, for now, just force ecore_dbus to be compiled (no reason not to as, again, it has only soft runtime deps). Brian On Mon, Apr 30, 2007 at 02:04:40PM -0400, Mike Frysinger wrote: > any chance we can get the dbus support turned into an optional component in > the window manager ? > -mike > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efreet and debian etch
On Sun, Apr 22, 2007 at 08:30:09PM +0200, Stark, Thomas wrote: > Hi, > > attached a workaround to bring up the menus on debian etch systems. > Maybe it's not the "right" way, but it helps me to see the system menus > in the e menu. > > Bye, > Thomas The menu spec lets you have different desktop specific application menus on your system by prefixing each one, and then specifying the desired one by setting the XDG_MENU_PREFIX environment variable. XDG_MENU_PREFIX="debian-" enlightenment_start will pick that menu for your. Basically, ensuring that a menu gets found by properly configuring the environment is the job of the distribution/packagers. However, since e is unreleased, and it would be nice to have things work 'out of the box' on as many distros as possible, a better solution would be to search the XDG paths for menus, and allow the user to select one (or more) to show in e's main menu. Regardless, no changes need to be made to efreet for this, just to how e uses efreet. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje_editor plans?
On Sat, Apr 21, 2007 at 02:51:06PM -0300, Gustavo Sverzut Barbieri wrote: > Hi, > > What is planned for edje_editor? > > It's almost usable, some edit fields are missing and most important, > I'd like to be able to add new states and define the transition > between them. With that, our designers would be able to do their work > without bugging us developers :-) > > Who is developing it? I'd like to help. Most projects in cvs has and AUTHORS file that lists the people who are working on it. That's the best place to look first. For edje_editor: Dave <[EMAIL PROTECTED]> Hasn't been very active lately, but we all get busy :) If you want to help, send him an email, then dig in and send patches. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ideas for a new 'desklet'-module api
On Thu, Apr 19, 2007 at 08:51:43PM +, [EMAIL PROTECTED] wrote: > > Simon wrote: > I think it would be good to have freely placed modules in > e17... but I just wonder if this should be the main method for having > large numbers of interesting "desklets" kinds of things in e. > Write an app that sets ecore_evas_alpha_set(ee, 1); ecore_evas_borderless_set(ee, 1); and run a compositor? Then, if desired set them to stack 'always below', and either alt-drag them around or use esmart_draggies? Who ever has enough empty screen space to see their desktop anyway? Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas keydown segfault
On Wed, Apr 18, 2007 at 11:54:28PM -0500, Brian Mattern wrote: > On Sun, Apr 08, 2007 at 03:49:08PM -0400, Christopher Michael wrote: > > Hi all, > > > > Mekius recently discovered a nasty segfault when trying to use the Enter > > key to dismiss a dialog. As it turns out, this affects all dialogs. > > After some digging into evas_callbacks.c I have come up with the > > following patch. I didn't commit because I'm not entirely sure that it's > > the proper solution, tho it does fix the segfault. > > > > I'm not sure this is a proper fix. It looks like it would just hide a > bug that is somewhere else. It seems that one of the callbacks is > triggering something that is setting obj->callbacks to NULL. I think > that either the place that this happens needs to be modified to honor > the 'walking_list' flag on the object, or the list walking needs to be > modified to break if obj->callbacks is NULL after calling a cb func. > > I only had a few minutes to look at this though, and I'm not very > familiar with the code. > > Brian > After some more digging, here's what I've come up with: * When you hit enter, the button widget is 'activated' * e_widget_activate() calls the No buttons callback, which deletes the dialog * this frees the evas, which frees its layers, which frees its objects, which happens to set obj->callbacks to NULL * e is still looping through its callbacks at this point, and segfaults * the NULL check in the aforementioned patch happens to work, but only by luck (the object pointer its accessing is now invalid). So, should we require that evas callbacks not free their evas? (E.g. force them to schedule a free and then actually do it outside of any callbacks) Or, should we alter evas to defer evas frees while walking an object's callbacks? Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas keydown segfault
On Sun, Apr 08, 2007 at 03:49:08PM -0400, Christopher Michael wrote: > Hi all, > > Mekius recently discovered a nasty segfault when trying to use the Enter > key to dismiss a dialog. As it turns out, this affects all dialogs. > After some digging into evas_callbacks.c I have come up with the > following patch. I didn't commit because I'm not entirely sure that it's > the proper solution, tho it does fix the segfault. > I'm not sure this is a proper fix. It looks like it would just hide a bug that is somewhere else. It seems that one of the callbacks is triggering something that is setting obj->callbacks to NULL. I think that either the place that this happens needs to be modified to honor the 'walking_list' flag on the object, or the list walking needs to be modified to break if obj->callbacks is NULL after calling a cb func. I only had a few minutes to look at this though, and I'm not very familiar with the code. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Tue, Apr 17, 2007 at 07:42:38AM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : raster > Project : e17 > Module : apps/e > > Dir : e17/apps/e/src/bin > > > Modified Files: > e_int_config_startup.c e_int_config_theme.c > e_int_config_wallpaper.c > > > Log Message: > > > dont stretch the preview - gets screen aspect all wrong. > There is also an 'aspect' widget that could possibly used for this. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_x with xcb backend
On Tue, Apr 17, 2007 at 08:35:01AM +0200, Vincent Torri wrote: > On Tue, 17 Apr 2007, Carsten Haitzler (The Rasterman) wrote: > and what about the case the xcb backend is used and the user does not use > these new functions, but the old ones ? The idea is to have the xcb back be a drop in replacement for the xlib one, where apps that were written using the old methodology still work properly (althuogh gain no benefit from using xcb). Then, slowly apps can update to take advantage of asynchronous calls. Also, a quote from: http://www.freedesktop.org/software/xcb/xfree86-xcb.pdf The reply list of an XCB connection is a reection of XCBs asynchronous reply delivery: replies arrive in request order but may be accessed out-of-order. So, on XCB's side they store the replies in a linked list. When you request one (using the cookie handle returned by the prefetch), it returns the requested one. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_x with xcb backend
On Mon, Apr 16, 2007 at 04:18:32PM -0500, Brian Mattern wrote: > On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote: > The problem i see is that for prefetch to really serve any purpose, the > code has to hit the event loop between prefetch and fetch/get. It will > be hard to guarantee that no code gets called in between that does a > full prefetch/fetch/get cycle (which would then be out of order). to answer my own question, sending several prefetches() will cause them all to go out at the same time when you do the first fetch(), so there is some benefit w/o hitting the event loop in between. (which i guess, due to the above should be avoided). Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_x with xcb backend
On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote: > On Mon, 16 Apr 2007, Brian Mattern wrote: > >The following will not work: > > prop1_fetch(); > > prop2_fetch(); > > prop1_get(); > > prop2_get(); > >(both get() calls will use the reply from prop2_fetch()) > > Yes, that last one will not work, and it is in purpose. The reason : when > you ask for a reply, you want to use the informations returned by the X > server. So there is absolutely no interest in calling _fetch if you don't > plan to use the corresponding _get just after. in that case, could you wrap up the _fetch() call into the _get() one, and get rid of the global that stores the reply between the two calls? > >B) although a bunch of prefetch() calls can be queued up, the > >corresponding fetch() calls must occur in the same order. > >e.g. one must do: > > /* queue up some requests */ > > prop1_prefetch(); > > prop2_prefetch(); > > > > /* some time later */ > > prop1_fetch(); > > prop1_get(); > > prop2_fetch(); > > prop2_get(); > > yes. It is important as the X server assure you that the replies are sent > in the same order than the requests. You might want different order, but > you will maybe have some problems. I can't do much more as it's in X > Window spec :) The problem i see is that for prefetch to really serve any purpose, the code has to hit the event loop between prefetch and fetch/get. It will be hard to guarantee that no code gets called in between that does a full prefetch/fetch/get cycle (which would then be out of order). I haven't looked at xcb's api, but what are the cookies for if not to allow one to fetch in a different order than prefetched? Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_x with xcb backend
On Mon, Apr 16, 2007 at 12:54:25PM -0500, Nathan Ingersoll wrote: > Nice work Vincent. As we discussed on IRC, there are a few changes to > the API I would like to propose to reduce the differences between the > two engines (Xlib or XCB) as it becomes more complete. I agree with Nathan that having different semantics in the two backends could cause confusion, and the current difference does constitute an API break. Also, I have a few other questions about the current implementation. prefetch() currently sends a request to the server, and adds a 'cookie' to the end of a queue to track this request. fetch() shifts a cookie off the front of the queue, and blocks until a matching response has been received, placing the reply in a global variable get() reads the global var populated by _fetch() and returns the actual data we want This requires a few things that aren't obvious from the api. A) fetch() and get() must be called in pairs. if you fetch() twice, you lose the reply from the first. e.g. you must do (assuming the requisite prefetches() have already been called): prop1_fetch(); prop1_get(); prop2_fetch(); prop2_get(); The following will not work: prop1_fetch(); prop2_fetch(); prop1_get(); prop2_get(); (both get() calls will use the reply from prop2_fetch()) B) although a bunch of prefetch() calls can be queued up, the corresponding fetch() calls must occur in the same order. e.g. one must do: /* queue up some requests */ prop1_prefetch(); prop2_prefetch(); /* some time later */ prop1_fetch(); prop1_get(); prop2_fetch(); prop2_get(); Since the whole point of this api is to make things asynchronous, the prefetches are likely to be in different parts of the code than the fetches. This would in the least have to be very clearly documented... Were these requirements intended? Or just side effects of the implementation? Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Thu, Apr 05, 2007 at 04:09:59AM +, [EMAIL PROTECTED] wrote: > > > > all in all this isnt a simple solution. the only way i see to > > > handle both methods is to have 2 calls. 1 to add a point relative > > > to origin and one to specify it absolutely. > > > > Two calls makes sense, but I think internally the point list > > should be relative to the object origin, and then convert to > > absolute coords at render time. This would allow us to do some > > sore of scaling based on object size (although some error would > > be introduced if the points were specified in abs coords). > > In order to eliminate cummulative errors, the vertex coords > must be stored as input (possibly modulo integer translations). > In order to minimize confusion from multiple coord systems > (and every time you have any kind of transformation, you basically > create a new coord system), or things like eg. mixing calls to add > points with calls to move/resize/rotate the obj (something which > I think ought to be avoided in usage), the inputs must have an > 'absolute' interpretation - either absolute rel to the canvas, > or absolute rel to an (untransformed) 'obj coord system'. > > I'd have to say that I think it would be best if the inputs > were taken rel to the (untransformed) obj, and nothing else. The > object size would grow with points added, or with resizing (scaling > the poly), and the bounding rect would change with rotations, etc.. > But the input vertex coords would have an absolute interpretation > as being rel to the (untransformed) obj. All of this is exactly what I had in mind, with an additional call that took points in absolute canvas coords and then converted them to object coords (at the current location/rotation/scaling). The use case I had in mind for such a function would be to add points based on mouse input. It would basically just do px,py = canvas_coords_to_polygon_coords(cx, cy) polygon_point_add(px,py) So, maybe we would just need the functions that map between the two coordinate spaces :) Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet englebass
On Wed, Apr 04, 2007 at 01:54:14PM -0500, Ravenlock wrote: > > -ext = strrchr(name, '.'); > ^ > I'm wondering if you accidentally removed the line above?? Yeah, that looks like a mistake. Committed. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
On Wed, Apr 04, 2007 at 06:36:41PM +0200, Simon TRENY wrote: > Does this mean, we don't have to unswallow/reswallow a swallowed object > anymore when we change its size with edje_extern_object_*() ? > Yes, that's the idea. Just curious, if you knew about the issue, why did you work around it instead of reporting it / fixing it? :) Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
On Wed, Apr 04, 2007 at 02:39:12PM +0200, Massimiliano Calamelli wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, 04 Apr 2007 14:29:06 +0200 > Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > > > It is possible to disable abstract sockets now. It is only used in > > ecore_dbus, and I think ecore_dbus will die soon. > > > > Sebastian > > Already disabled with --disable-ecore-dbus, but configure check it > again. > I added the abstract socket code and the macro to check for it. I have no experience with cross-compiling, so didn't know that it would be an issue. Disabling ecore_dbus won't help because the feature is in ecore_con. Someone just needs to add a configure option to explicitly disable (thus avoiding the check) or determine another means of checking that also works when cross compiling. If no one else gets to it, I'll try to look in the next few days. Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Wed, Apr 04, 2007 at 01:39:51PM +0900, Carsten Haitzler wrote: > all in all this isnt a simple solution. the only way i see to handle both > methods is to have 2 calls. 1 to add a point relative to origin and one to > specify it absolutely. Two calls makes sense, but I think internally the point list should be relative to the object origin, and then convert to absolute coords at render time. This would allow us to do some sore of scaling based on object size (although some error would be introduced if the points were specified in abs coords). Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Wed, Mar 28, 2007 at 09:28:16PM +, [EMAIL PROTECTED] wrote: > > > > The current code has the polygon's coordinates in the object's > > > coordinate space. > > > > That doesn't seem to be true. evas_object_polygon_point_add(obj,x,y) > > adds the point (x,y) to the list of points, not the point > > (x - min_x, y - min_y). > > Like Brian, I too had thought that the interpretation was > the poly points were taken to be rel to whatever the obj's current > position.. but that's not so. The obj's pos is taken as the min of > the poly vertex coords, and thus you are correct that the present > poly positioning semantics is mostly borked. Yeah. My mistake there. The current code was a patch from a few months back, that was apparently only half-correct. I've reverted it. > Note that things like poly and line objs have never really > been given much attention in evas - they are still waiting for a > much more thorough rewrite at some point - and thus things there > are likely to be rather shabby right now (anyone who feels like > they would like to help setup a good, fast, path-rasterizer is more > than welcome to lend a hand :)). Anything vector-like in evas needs a once over, as it was probably quickly written and never really used :) Its pretty low priority for most of us though, so help would definitely be appreciated. > > Now, this actually brings up a question: Just what should > the interpretation be of vertex coords (in lines, polys,..), and > of the 'geometry' of such path-defined objs? > One could take the semantics to be that the vertices are > defined rel to whatever the obj's pos is, and have the obj's set > geometry clip the poly's extent. This seems more desirable to me... > A quick rundown of the options I) Absolute canvas coordinates _point_add() takes a coordinate in canvas coords, and draws that point at that coordinate, completely ignoring the object's position II) Relative object coordinates _point_add() takes a coord relative to the object, so if the poly is moved to (10,10) the point (5,5) will be drawn at (15,15). III) Polygon coordinates _point add() takes points in an abstract space. This space is located such that the origin of the object corresponds to top left of the bounding box of the polygon's points. Is the current method (without the botched patch) seems to be (I) from a quick test, but i haven't looked at the code much. From what you say above, it sounds like its SUPPOSED to be doing (III). I'm impartial as to whether (II) or (III) is better. (II) is a bit more predictable, though. As for the size clipping the poly's extents, that makes some sense, but I think the default expected behavior would be for it to be large enough to show all of its points. So, maybe it would be better to ignore the size? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
Achim wrote: > I've found a bug in the polygon drawing code of evas: In the file > e17/libs/evas/src/lib/canvas/evas_object_polygon.c in function > evas_object_polygon_render the lines > > p->x + obj->cur.geometry.x + x, > p->y + obj->cur.geometry.y + y); > > should read > > p->x + x, > p->y + y); The current code has the polygon's coordinates in the object's coordinate space. E.g. relative to the object (although the object size is ignored). By default an object is located at (0,0) which means the two spaces match up. If we change it, then one would not be able to use evas_object_move() to move a polygon. So, I don't think this is a bug, but rather just behavior that is other than what you expected. Are you moving a polygon object and expecting it not to move? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] External modules
E is in the process of being moved to use efreet instead of ecore_desktop. One consequence of this change is that the module.desktop files will not load because they don't comply with the .desktop spec, which requires that a Type field be present. For now, use Type=Link, remove any X-* fields, and change the Icon field to a unique name (e-module-MODULE_NAME). Move module.edje to e-module-MODULE_NAME.edj and change the file name in the gadcon icon callback (typically called _gc_icon()). In the future, we may want to move the gadcon list to also use efreet for its icon (so that themes can override them eventually). I have converted tclock, and will do mail, and possible more if i have time. The next week or so will probably be a bit rocky as these large changes go through. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Thu, Mar 22, 2007 at 02:31:57PM +, [EMAIL PROTECTED] wrote: > > Simon writes: > > > Actually, I see no real point in coding with Etk/Ewl an aplication > > that already exists with Gtk or Qt. It would "only" offer more > > consistency with an E desktop, and some eye-candy effects but it's > > If no 'existing' gtk/qt apps are ever written with ewl/etk, > then there never going to be any image viewer apps, any text editors, > or any of the other 20,000+ apps that exist -- you're going to have > to think real hard to make up a 'brand new' kind of app that no one > has ever done before in gtk/qt, just to make it 'worth' doing in > e's toolkits?? > > > quite a waste of time imho. We should try to think differently, > > because we have tools (Edje/Evas) that allow us to do things > I think the sentiment he's trying to get across, which is one I share, is that there is little point in rewriting a gtk/kde app in an e widget set if it looks and functions exactly the same. E.g. using emphasis (or whatever the glade lib is) with a gnome app's glade file is a lot of effort (recreating the backend functionality) with the only gain being glinty buttons. The point is NOT that we can't use new, innovate image viewers, text editors, etc. But, we need to sit and think about how we can improve on the current 'desktop app' idioms. Elicit is a simple enough application that it can have its gui entirely defined in edje. I've thought several times about breaking some of its layout out into some smart objects (e.g. the a simple notebook smartobj). However, this would severly dampen what is possible from the theming standpoint. Tokyo has done some amazing versions of pared down single panel (no tabs) themes for elicit. You'll also notice that elicit has no proper configuration dialogs. So, if a theme doesn't provide a theme selector, then you can't switch themes. For small apps like this, this is an arena where traditional packed widgets fit in. Many larger apps (image viewers, music players, etc) could probably be done in a similar fashion. E.g. a free form edje ui for the primary functionality, with a packed widget set for dialogs. But, it really depends on the app in question (and the imagination of the author). rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Tue, Mar 20, 2007 at 12:15:59AM +0900, Carsten Haitzler wrote: > agreed to all the above - except i think test code could/should go into the > now > nice and shiny e17/test/... tree :) (imho). As long as we make this tree well known (e.g on whatever new 'accessing CVS' page we build). :) I've noticed several people who started learning edje after you split out the test tree who never knew about the edje test app (which is very helpful when initially learning EDC). rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [ENM] A network manager front end
On Sun, Mar 18, 2007 at 06:15:59PM +0100, watchwolf wrote:
> hello,
>
> I want present you a new application writed with etk for E17.
> The application can have some bugs for you as segv :p . The code is not
> perfect, I need to add some tests & errors outputs. The next steps,
> before add new functions, is to clean/correct the code.
>
> You can see screenshots & the source code on my blog.
> http://watchwolf.fr/index.php?post/2007/03/18/%5BE17-Network-manager%
> 5D-Pesentation
>
> To compile us this makefile: etk/Makefile.
>
Just to be clear, this doesn't seem to have anything to do with
NetworkManager (http://www.gnome.org/projects/NetworkManager/), the dbus
lib / api, right? (Looks like its a frontend to i{f,w}config / route /
etc).
Is future NM support planned? Or is the naming similarity just a
coincidence?
rephorm
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Sun, Mar 18, 2007 at 03:29:13PM +1000, David Seikel wrote: > Raster made this commit about two weeks ago : > > > a lot of patches - also my work on moving the IO stuff in e_fm to a > > slave process to stop e from ever "locking up". this unfortunately > > breaks the other source stuff and thus breaks the app editor config > > dialogs and anything using fm2 for .desktop stuff from the e > > applications/all repo. i am doing this as i expect this to go away > > with efreet anyway so not too much of an issue. not all fm operatiosn > > work currently - note. so beware. it can view files though :) > > So I have been holding off on any attempt to repair these things and > just sitting and waiting for efreet to solve all our problems. The > users are now complaining about the broken app editor. I have not seen > any efreet commits for a while, is it going to replace ecore_desktop > soon? Or should I put in some effort to patching up the app editor > while we wait? Efreet is pretty much complete, other than being itegrated into e17. Unfortunately, dan doesn't use e17 on anymore and seb and I have been pretty busy lately. > > What state of development is efreet in anyway? It is mostly complete. Loading .desktop files, finding icons and parsing / building menus all works. Executing desktops (and even downloading the files if necessary) has been implemented. There may be a small amount of work left to be done to properly do menu editing. I think we just never decided to what degree we want to integrate things. E.g. converting directly from efreet's menu structures into an E_Menu, or doing an intermediate step and building .order files first. But, I'm busy with work, planning a wedding, and preparing for grad school in the fall. So, its hard to find the motivation to work on this in what little free time I have. :( rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] TODO item(s) need clarification.....
On Fri, Mar 16, 2007 at 09:10:56AM -0500, Eric Schuele wrote: > hehe... a wobble transistion. cool. you think each window individually > should wobble or the entire desktop? More like when you switch desktops, the old desktop's windows immediately disappear, and the new desktop's windows appear, but wobble for a second. However, I don't see how this would be possible without a compositor. While on the topic of desktop transitions does anyone else notice that e17's seem pretty slow? they get choppy when i have large and/or many windows (on an athlon 64 3000+). e16 handled sliding windows beautifully on an 800mhz box... rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] TODO item(s) need clarification.....
On Fri, Mar 16, 2007 at 06:44:41PM +0200, Hisham Mardam Bey wrote: > The other alternative, as mentioned, would be to propagate theme > changes without a restart. We have also discussed this issue before, > and the initial thought was that it was indeed quite complex as it > would require all sorts of recalculations, widget creation, > re-swallowing, etc. It is not really worth the hassle. Edje will now automatically reswallow any swallows when you call edje_object_file_set(). So, it shoudl just be a matter of running through edje objects, resetting files and resending signals to get to the current state of the widget. Setting font classes *shouldn't* require rebuilding the objects, so I'm not sure why the font dialog triggers a restart at the moment. Anyway, I really think that this is the way to go. Since *most* layout is handled by edje, it will be recalculated automatically as the file is loaded and the swallows are reswallowed. Widgets that do custom layout typically have a configure type call that recalcs layout. So, it would probably just be a matter of adding a call to each widget to re-send the state signals. I think this would be a cleaner route than tracking internal dialogs and re-showing them. As more functionality is added to e, restarting will become more and more of a cost (dbus connections resetting, having to re-query daemon state, etc)... rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] TODO item(s) need clarification.....
On Fri, Mar 16, 2007 at 07:17:27AM -0500, Ravenlock wrote: > Hello, > > Can someone please elaborate on these items for me? > > * winlist could divide windows up into blocks - sub-lists within a > container per desktop (with stick windows considered to live on the > "current" desk when winlist starts) > > Is it just that someone wanted the windows grouped within the winlist > (similar to how the clientlist is now)? Right now the winlist only shows windows on the current desktop. I think the idea with this was to have it show windows in other desktops also, but group them somehow. The details were never really fleshed out, though. > * internal windows (config dialogs, etc) should re-open after a restart > > Just wondering *why* this is desired. Seems like a lot of book > keeping... for little value. Just wondering what the motivation for > this one was. This is only really an issue when changing themes. So, maybe only the theme dialog needs to re-open and only after a restart due to the theme being changed? Alternatively, we could try to implement theme switches without requiring a restart. But, that's probably more trouble than its worth. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore mej
On Thu, Mar 15, 2007 at 12:51:53PM -0400, Michael Jennings wrote: > Actually since it's possible my commit message got things off on the > wrong foot and ended up causing this whole mess, I went ahead and > re-applied the patch along with a fix for ecore-config. Hopefully the > correct fix. :) > > Michael > Thanks :) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore mej
On Thu, Mar 15, 2007 at 11:55:08AM -0400, Michael Jennings wrote:
> On Thursday, 15 March 2007, at 08:42:31 (-0500),
> Brian Mattern wrote:
>
> > The correct response to a dev breaking cvs is "hey, this broke, can
> > you fix it?"
>
> If the breakage is minor, I agree 100%. But in this situation, every
> single project that used ecore was broken. There are times when it
> has been necessary to revert big breakages until the person who broke
> it has a chance to fix it. raster's done it, I've done it...heck,
> you've even probably done it.
I'm far too lazy to revert peoples changes :)
I'll concede that in this case it was big enough to warrant reverting.
Maybe better commit messages ("this breaks compilation of anything that
depends on ecore, revert it for now") would help avoid hurting peoples
(admittedly a bit sensitive) feelings.
This project is just hobbling along with very few devs, most too busy or
too fed up with the squabbling to devote much time or effort.
So, mej, tone it down a bit (i know, its hard for you...) :)
And, caro, don't take everything so personally. Just fix what was broken
and re-commit your changes.
rephorm
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore mej
On Thu, Mar 15, 2007 at 01:25:00AM -0400, Michael Jennings wrote: > On Thursday, 15 March 2007, at 06:21:21 (+0100), > Vincent Torri wrote: > > > 1) I have tested them. it works for me > > Apparently you failed to test whether other applications would > subsequently build with the changes you made. They won't. The correct response to a dev breaking cvs is "hey, this broke, can you fix it?", not "I'm a dick". > > 2) you have reverted all the commits without telling what is wrong for > > each commit > > See #E. The problem was noted by several people across multiple > applications/libraries. Not everyone is in #e (its hard to take that mindless drivel for more than a few minutes a month). So, "see #e" is a worthless response. Now, several people having build issues does indicate that the build is broken. But, people temporarily break cvs all the time (including me, raster, and possibly even your holiness). Either fix it or wait for the dev who broke it to fix it. (Or revert your local tree to before the patch that broke things). > > 3) why the autoconf changes (I guess that's the main problem) does not > > work for you > > What does ecore-config --libs print? That should point you in the > right direction to fix your patch. Finally some useful information... Amazing. (Typically it takes a few more heated emails back and forth before anything like this appears). So, in summary. I) Stop treating people like shit. II) Let them know when they break things BEFORE you revert their changes. III) Stop treating people like shit. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Str new feature...
On Mon, Mar 12, 2007 at 12:41:41PM +0100, Stéphane Bauland wrote: > + * @param max_tokens The maximum number of strings to split string into. If > this is less than 1, the string is split completely. > + if ( max_tokens < 1 ) max_tokens = 100; Filthy lies :) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Str new feature...
On Mon, Mar 12, 2007 at 12:41:41PM +0100, Stéphane Bauland wrote: > Hi people. > > I needed a function to split a string into a list. My first func used > Ecore_List * as return value, and dourse said me that's not really good. > He said me to return a char ** so i did it. And i put it under ecore_str. Since you're using an ecore list internally, I don't see why you shouldn't just return that? What was the reasoning behind why "that's not really good"? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] To rephorm
On Wed, Mar 07, 2007 at 08:50:40AM -0600, Nick Hughart wrote: > Well I finally got the time to sit down and try and compile this, but I > get an error: > > /usr/bin/ld: cannot find -ledbus > > Obviously I don't have edbus yet since I'm trying to build it :) > > It tries to make hal first, which is probably why it fails. > > Was able to get it installed by hacking the makefile to take out the > hal subdir and then building edbus and installing, then putting it back > in. So everything works, just need to somehow make sure the subdir is > built last, not sure how to force that though. > Yeah. I threw together the autofoo stuff really quickly. Guess it passed make distcheck for me because I already had libedbus installed. Really, the hal stuff belongs in a separate lib. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] To rephorm
On Mon, Mar 05, 2007 at 11:02:27PM -0600, Nick Hughart wrote: > Hi, I think you had posted a link to your in progress e_dbus code, but > I was wondering if you could post it again. I not quite sure how done > it is, but would like to use it in a project I'm doing and in the > process hopefully find some bugs and such to help you out. Its at: http://rephorm.com/files/code/e_dbus-0.1.tar.gz I'll try to find some time to add a few more comments and stick part of this in proto so others can pick up on it. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The edc gradient type 'type'
On Mon, Mar 05, 2007 at 10:21:53PM +0200, ?? wrote:
> Is there any particular reason why the gradient type in edc is a string,
> instead of a keyword like the rest of the types?
>
> when you write 'gradient {type: ', you can't write anything other than
> "linear" or "radial", right? So why isn't that statement parsed as
> 'type: LINEAR' or 'type: RADIAL'?
IIRC, the evas gradiant types are strings, so I just used these directly
in the edje format. I originally considered doing keywords, but I was
under the impression that the string type names existed to allow future
pluggable gradient types. So, using the strings directly in edje would
allow support for such things.
But, I'm not certain what the plan actually is/was. Grads in evas are
(unfortunately) not used a whole lot and have little documentation. If
pluggable grads isn't on the future feature list, then I'm not opposed
to codifying the grad types in edje.
rephorm
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_strbuf_replace
On Sun, Mar 04, 2007 at 02:06:44AM +0100, Peter Wehrfritz wrote: > This mail is mainly addressed to rephorm, but every suggestion or > criticism is welcome. Here is a patch to add ecore_strbuf_replace() and > ecore_strbuf_replace_all(). I doesn't reduce the size of the buffer if > that is possible. Cause the current calculation of the maximum step size > is bijective. So it would probably be better to determine the max step > depending on the buffer size and not on the previous step size. > > If you like the patch I'll commit it. > Go for it. I don't have time to give it more than a quick skim, but feel free to modify ecore_strbuf as much as you want. :) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje data speedup
On Thu, Mar 01, 2007 at 09:35:13PM +0100, Tilman Sauerbeck wrote: > ACK. I believe raster's reasoning for using lists in various spots that > would intuitively like to be hashes was the size of the entries that are > stored. IIRC evas/ecore_evas also use lists to store key/value userdata. Yes, but the assumption is that there won't be many data nodes. If there ARE (like in ewl themes which map generic keys to actual groups), then you get the performance hit. So, its a tradeoff. This change (as far as I understand) would be a single hash per edje file (~1K). (What's the typical size of an edje file in memory?) E's theme (typically) a single file, so this shouldn't be too bad. It could also only allocate the hash for files that actually have data. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje data speedup
On Thu, Mar 01, 2007 at 08:13:19AM -0600, Nathan Ingersoll wrote: > On 3/1/07, Christopher Michael <[EMAIL PROTECTED]> wrote: > > > > Just my 2 cents, but with gains like that how can we NOT use a hash :) > > Right, we're going to use a hash one way or another, just a question > of if we want to break the edje format to do it. :) In this case, old files will just need to be recompiled (edje_recc should do it), so I don't see a problem. At some point we'll need to start versioning the file format and keeping the code compatible with old versions, but that can probably wait until release. (e.g. stay compatible with release versions, but not the various iterations in between). rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compiling EWL fails due to some reason (not code)!
On Wed, Feb 28, 2007 at 06:30:33PM +, Paulo J. Matos wrote: > On 2/27/07, Michael Jennings <[EMAIL PROTECTED]> wrote: > > On Tuesday, 27 February 2007, at 14:38:44 (-0600), > > Brian Mattern wrote: > > > > > But the practical suggestion in the email (removing crufty installs from > > > old prefixes) is correct, no? > > > > Not necessarily. The .la file which refers to the now-missing > > /usr/lib/libedje.la could be anywhere, even in /usr/local. The > > problem is that something got built when edje was still in /usr/lib. > > That something needs to be found and rebuilt. > > > > That's probably it since I found a few only installs of E17 libs > floating around /usr/lib. It seems I was not able to remove all since > I'm still getting the problem. Is there any straightforward solution > coming to the mind of anyone? I'll be running grep -R "libedje" > /usr/lib but it'll probably take forever and even if returns nothing > I'll still be in trouble. Any ideas? look for /usr/lib/libe*, and delete any enlightenment related ones, then recompile everything in order (eet, evas, ecore, embryo, edje, ...) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compiling EWL fails due to some reason (not code)!
On Tue, Feb 27, 2007 at 03:02:29PM -0500, Michael Jennings wrote: > On Tuesday, 27 February 2007, at 13:57:27 (-0600), > Brian Mattern wrote: > > > The error message about /usr/lib/libedje.la not existing indicates > > that you probably have an old partial install in /usr/lib. ld is > > finding some lib there (instead of /usr/local/lib) which refers to > > /usr/lib/libedje.la (which apparently no longer exists). > > ld does not parse .la files. > Sorry, libtool. But the practical suggestion in the email (removing crufty installs from old prefixes) is correct, no? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compiling EWL fails due to some reason (not code)!
On Tue, Feb 27, 2007 at 07:53:46PM +, Paulo J. Matos wrote: > On 2/27/07, Michael Jennings <[EMAIL PROTECTED]> wrote: > > On Tuesday, 27 February 2007, at 19:07:42 (+), > > Paulo J. Matos wrote: > > > > > grep: /usr/lib/libedje.la: No such file or directory > > > /usr/bin/sed: can't read /usr/lib/libedje.la: No such file or directory > > > libtool: link: `/usr/lib/libedje.la' is not a valid libtool archive > > > > > > Well, I can't find a single line referring to /usr/lib in this linking > > > command line. > > > Can this be a hardcoded line in ewl make somewhere? > > > > > > Does anyone know what's happening? > > > > One of the .la files used in that link line refers to > > /usr/lib/libedje.la. > > > > Can't find anyone on the line I posted regarding /usr/lib/libedje.la and > # pwd > /usr/local/stow > # grep -R "/usr/lib/libedje.la" * > # > > finds nothing. > > Why do you say that? The error message about /usr/lib/libedje.la not existing indicates that you probably have an old partial install in /usr/lib. ld is finding some lib there (instead of /usr/local/lib) which refers to /usr/lib/libedje.la (which apparently no longer exists). Make sure you fully remove any efl libraries installed into /usr/lib. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] state of ecore_dbus
On Mon, Feb 26, 2007 at 08:10:48PM +0100, Sebastian Dransfeld wrote: > Hannes Janetzek wrote: > > Hi, > > I have started to make a module for e17 to control NetwokManager. I > > would like to use ecore_dbus for that, but it seems > > ecore_dbus_message_new_method_return doesn't work correctly. (I need > > this function since NetworkManager gathers user preferences from the > > client.) so when the return message is sent a > > ECORE_DBUS_EVENT_SERVER_DEL is produced on the sending side and a dbus > > timeout is recieved on the other (method calling side). > > Am i doing soemthing wrong or is this the expected behavior atm? If so, > > do you have any hints what needs to be > > done to fix this? > > Can you show some sample code? And check whether the dbus samples work. > > Sebastian > The ecore_dbus_receive_test sample (in test/orig/ecore) doesn't actually send a reply. (Which would definitely cause the other end to eventually time out if it was expecting one). So, the method_return code probably has never been tested. Ecore_DBus is pretty young, and still missing some functionality. If you want to use it, you'll probably want to get familiar with its code so you can fix any bugs you run across and implement any missing functionality you need. As an alternative approach, I started a simple wrapper around dbus that hooks it into e's main loop. It provides a few convenience functions for setting up method receivers, etc, but requires using the lowlevel libdbus api for many things. I probably won't have any time in the next couple months to work on this, so I've put up a tarball at: http://rephorm.com/files/code/e_dbus-0.0.1.tar.gz It includes part of the hal dbus api wrapped up into a lib and a demo ewl app using that. I would love to see someone take this and ecore_dbus and do some benchmarks. In my opinion, unless we can get some significant speed/memory gain from ecore_dbus as opposed to libdbus, I don't see the point of having an independant implementation of the spec. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Can't undertand engrave api
On Sun, Feb 04, 2007 at 04:54:44AM +0100, DaveMDS wrote:
> Hi all,
> Have two problem with engrave:
>
> 1. What is the "state2" and "value2" param in:
> engrave_program_action_set(ep, action,state,state2,value,value2)??
> State/Value is the state to set in the target(s) in a STATE_SET action.
> But what state2/value2 refer to?
value2 is used as the y component of the various drag actions
action: DRAG_VAL_SET value value2
state2 is used by SIGNAL_EMIT actions as the second param ('source')
action: SIGNAL_EMIT state state2
>
> 2. Where is the "name" and "source" params of the SIGNAL_EMIT action?
> I cant find those value in engrave.
state and state2 respectively
maybe these should all be renamed as string_val, string_val2, double_val and
double_val2?
see engrave_out.c for more info on how internal fields map to edc fields
rephorm
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Sun, Jan 28, 2007 at 02:22:51AM -0500, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : raster > 3. add removable device support to e17's fm - via dbus/hal. seems to work > well :) (requires pmount to mount devices though) > Keep in mind that ecore_dbus currently has the little endian flag hard coded. So, it most likely doesn't work on big endian systems. (Just a heads up). rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e onefang
On Fri, Jan 26, 2007 at 05:00:04AM -0500, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : onefang > Project : e17 > Module : apps/e > > Dir : e17/apps/e/src/modules/temperature > > > Modified Files: > e_mod_config.c e_mod_main.c > > > Log Message: > Increase the number of i2c sensors to 4. The only useful one on my > motherboard (ASUS A7V333) is the fourth one. Others may find this handy as > well. > Would it be possible to query the # available instead of hard coding it in? E.g. if someone else has a device with 5... or 6, or whatever. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje command
On Fri, Jan 19, 2007 at 11:11:27PM +0100, Andreas Volz wrote: > Hello, > > some time ago there was a "edje" command to view my edj files. But it > seems to be removed It should be in cvs in the test module rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efreet - freedesktop menu/icon/desktop spec implementation
After a few weeks of spare-time development, I'd like to announce Efreet, a new implementation of the XDG (freedesktop) specs for Icons, Menus and Desktop Entries. The current implementation, Ecore_Desktop, while a commendable effort for a sole developer under time constraints, leaves a bit to be desired. So, dj2 and I started reading through the xdg specs, and playing around with our own implementation, code named Efreet. After speaking with onefang about some of the issues with ecore_desktop, he said it was due for a rewrite, so we continuted with our replacement implementation. Rbdpngn and Engelbass also pitched in. Currently we have code to build menus, find icons, and load desktop entries complete. There are a few things left to finish (most importatnly executing desktop entries), but it is almost at a point where we'd like to start integrating it in to e17. The code, for those interested, is available from subversion at: http://everburning.com/svn/efreet Before we hook e17 in to efreet, there are a few issues I'd like to bring up. E currently uses a hands off 'read only' approach to the XDG structure, copying the structure in to the format that e previously used (.order files). This made sense given ecore_desktops roots as an addon program that simply connected the two. But, since we're already going to be loading up the xdg menu format, is there any reason to not just use that directly? This would have the added benefit that as apps are added through a package manager, they would just show up in the menu as they do in every other desktop (without having to go to config > application menus > Regenerate / Update "Applications" Menu). The next question is, assuming you guys see it as a viable replacement for ecore_desktop, do we stick this somewhere in libs (as efreet or e_xdg, or whatever name) or do we cram it in to ecore? My vote is that we stop bloating ecore in the name of a 'dependency freeze' and keep proper separation of libraries. (Its all 'new code' that needs to be verified and tested regardless of where we stick it). Let us know what you guys think. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: mail devilhorns
In a recent commit to the mail module:
> @@ -289,10 +286,10 @@
> if ((num > 0) && (ic->config->use_exec) && (ic->config->exec))
> _mail_start_exe (ic->config);
>
> - is->current = is->current->next;
> + is->current = is->clients->next->data;
> if (is->current)
> {
> - if (is->current->data)
> + if (is->current)
> is->state = IMAP_STATE_SERVER_READY;
> else
> _mail_imap_server_logout (is);
is->clients is a pointer to the head of the list.
is->clients->next will thus always be a ponter to the second client.
(e.g. not what you want).
I think the original code was correct, there was just a header change
(is->current from _Client -> Evas_List) that was missed, causing it not
to compile.
rephorm
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Misstyped word
On Sat, Jan 13, 2007 at 06:09:42PM -0500, Michael Jennings wrote: > On Saturday, 13 January 2007, at 22:41:04 (+0200), > Ag. System Administrator wrote: > > > After i've translated 95% of them i should stop? > > Yes, you should...but then you never should've started. :) > > Language names are not subject to translation; they should appear in > native form. To do otherwise would defeat the purpose of "natural > language support." Imagine having to learn the name of your native > language in EVERY OTHER LANGUAGE. That would be silly. > Well, then shouldn't we change the list in e_int_config_intl.c to show the names of the languages in their native language? (Otherwise they have to learn the name of the language in English, which is also silly, isn't it?) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Misstyped word
its 'Tyap', the name of the 'kcg' locale (of Nigeria) rephorm On Sat, Jan 13, 2007 at 03:00:59AM +0200, Ag. System Administrator wrote: > Hi, > > just small typo at e/src/bin/e_int_config_intl.c:188 > Written "Tyep", should be "Type" > > :) > > > Thanks, > Dan > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Smart objects
On Mon, Jan 01, 2007 at 03:43:42PM +0100, Jorge Luis Zapata Muga wrote: > On 7/2/06, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > On Mon, 19 Jun 2006 01:17:03 +0200 "Jorge Luis Zapata Muga" > > <[EMAIL PROTECTED]> babbled: > > > > > Hi all, > > > i have some doubts-ideas about evas smart objects, > > > > > > 1. the API > > > in order to add an object to a smart object you have to do > > > _member_add(o, s) and to delete _member_del(o,s). On the code of both > > > an evas smart object actually stores the members on a list but theres > > > no function to retrieve them, Evas_List * _members_get(s), so when you > > > code an evas smart obejct and you need to keep track of the objects > > > you have, you need to duplicate the list and code a different function > > > to do that. > > > > a get call would be useful and a good idea. :) > > hi all and happy new year =) > > ive retaken this thread to not add another one about almost the same > topic (Evas smarts) :) > i know the get call is indeed usefull, but im having another "problem" > with evas smarts, the member_add/member_del functions. Wouldnt be good > to have the smart class also define (if it wants) a member add/del > callbacks? > > all smart classes define their own api to add a member in case they > want to track down/do something with the objects added/deleted which > is good, but imho isnt consistent because if someone uses the "normal > api" to do that (evas api) the smart object will be in a inconsistent > status. one solution is to do everything through evas api, do a > _member_add and the smart callback will be called. > > If the smart also wants to add its own objects in case an object is > added it still has to differentiate in the callback if the object > added is its own or another, but isnt a problem i think =) > > what do you think? _member_add/del are more for internal use of the smart object to tell evas which objects are part of it (for event, stacking, layering, purposes). If a smart objects acts like a container, i think it makes more sense to have a specific api for that (there may be multiple ways of adding children to that container) rather than using a generic member_add() with a callback. I may be misunderstanding your request. If so, could you give a specific example of what you're proposing? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Custom screensaver to override E's desklock (work in progress)....
raster said: > I don't see any problem with this feature :) setting a command is ok- though > what i think would be better is to have .desktop files with the screensaver > commands and then just select from ones (maybe of Type=Screensaver) so you can > pre-package configs for xscreensaver and other screensaver 3rd party apps out > there. This is a good idea, but having to pre-guess which possible screensaver programs one may want to use isn't ideal. So, we'd at least need a "add screensaver" option that builds the .desktop file. Nikolas Arend said: > > The current/new implememtation of the screensaver and desklock settings > is not exactly what I was hoping for and IMHO not consistent. > Although I can set a custom screensaver/desklock command, this command > will be used for both screen-saving and desklocking as far as I can see. > So when I set "Enable X screensaver" leaving "Lock when the screensaver > starts" unchecked, but use "xlock" as my custom screensaver/desklock > command (since I have problems with PAM), this command is used every > time the screensaver activates (and of course locking my screen which I > don't want). Do you have the PAM headers installed? Is pam support getting compiled in when you build e (check the value of HAVE_PAM in e17/apps/e/config.h)? (We probably need to fix desklock to not lock if pam isn't compiled in.) > In order to have locking and screen-saving decoupled, I think there > should be two custom command lines, one for the screensaver and the > other one for the desklock command. The "Lock when the screensaver > starts" option should be deactivated (greyed out) as soon as there is a > custom screensaver command defined (which should take care of whether or > not to lock the screen when starting). > The custom desklock command should only be used when an explicit screen > lock (e.g. launching "Lock Screen" from the system menu) is requested. > This makes sense. Possibly coupled with the above suggestion from raster. So, a dropdown/ilist for each, with a button to add a new one? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Add application key bindings from border menu....
On Thu, Dec 21, 2006 at 04:01:58PM -0600, Ravenlock wrote: > Hello, > > Here is a patch that will add a border menu item that allows you to > enter a key binding for the current app. > > It utilizes the existing key binding config dialog. When launched from > the border menu, it will immediately prompt for the binding. It then > selects the "Defined Command" as an action, and fills in the "Action > Params" with the present app's command line args. > > Quirks/Limitations: > Well, in short... the command line and args may not be exactly what > you expect. For example, some apps are started via shell scripts. > Firefox and Thunderbird for example. If you start them up and create a > key binding in this fashion, you get firefox-bin and thunderbird bin > respectively. This will not launch those apps (on my machine anyway). > Additionally, complex command lines may not be as you expect either. > Command lines with pipes and `command substitutions` in particular. > > Comments welcome. > For apps that have associated .desktop files, we could possibly use that to determine how to launch it properly. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_modules net and wlan fixes
On Thu, Dec 07, 2006 at 11:53:53AM -0600, Brian Mattern wrote: > On Thu, Dec 07, 2006 at 05:52:40PM +1000, David Seikel wrote: > > On Tue, 5 Dec 2006 18:33:06 -0600 Brian Mattern > > <[EMAIL PROTECTED]> wrote: > > > > > Something like this is what I had in mind when I drew > > > http://rephorm.com/files/old/meter-big.png a few years ago. I had > > > implemented a bit of it, then realized that I don't really have much > > > going on that I need to measure... > > > > I get a time out from that link. > > Yeah, the server its on (the same as edevelop.org) seems to be down > again :( > Try now - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_modules net and wlan fixes
On Thu, Dec 07, 2006 at 05:52:40PM +1000, David Seikel wrote: > On Tue, 5 Dec 2006 18:33:06 -0600 Brian Mattern > <[EMAIL PROTECTED]> wrote: > > > Something like this is what I had in mind when I drew > > http://rephorm.com/files/old/meter-big.png a few years ago. I had > > implemented a bit of it, then realized that I don't really have much > > going on that I need to measure... > > I get a time out from that link. Yeah, the server its on (the same as edevelop.org) seems to be down again :( - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_modules net and wlan fixes
On Wed, Dec 06, 2006 at 03:29:48AM +1000, David Seikel wrote: > On Fri, 01 Dec 2006 18:32:41 +0100 "Stark, Thomas" <[EMAIL PROTECTED]> > wrote: > > I eventually want to replace all these system monitoring modules with > some common code that resembles the way that gkrellm handles graphs. > I would vote for a set of graph views. Some would need to be smart objects (e.g. one doing amplitude vs time, possibly with multiple graphs on the same chart). Others could be entirely up to the themer. Simply allow a means for the theme to provide different types (each being a separate group) and use messages to pass in the current value of the the measured qty (maybe both as an absolute value, set on a text part e.g "480 MB" and as a percentage "80%"). Then you would just need a set of pluggable 'measurables' (mem, net, wireless signal strength, etc) and a means to connect measurables to view types. Something like this is what I had in mind when I drew http://rephorm.com/files/old/meter-big.png a few years ago. I had implemented a bit of it, then realized that I don't really have much going on that I need to measure... But, for all those meter-junkies out there, this would provide something much nicer and more flexible than gkrellm. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] evas_smart_new() api
A while back, layer and stacking handling for smart object members was moved into evas itself, removing the need for the layer_set, raise, lower, stack_above and stack_below callbacks. However, the api remained the same, so now every smart object has 5 NULL's in the middle of its evas_smart_new() call. Any objections to removing these from the API (other than the fact that we have to trudge through cvs and delete a bunch of NULL's)? I'd prefer this to having deprecated API on release. (and yes, i'd be willing to do most of the work) :) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e devilhorns
On Tue, Nov 28, 2006 at 12:57:20AM +0800, Stafford Horne wrote: > On Mon, 27 Nov 2006 08:34:57 -0500 > Christopher Michael <[EMAIL PROTECTED]> wrote: > > > Stafford Horne wrote: > > > On Mon, 27 Nov 2006 07:57:03 +0100 > > > Anders Troback <[EMAIL PROTECTED]> wrote: > > > > > >> Just want to say: Good idea :-) > > > > > > I now have to go through all categories to find what I am looking for. > > > Its probably just me though. I don't mind much because I only look at... > > > never. > > > > > As opposed to scrolling an exceedingly, ever-increasing, long list of > > the same options? At least this way, things are broken up into their > > proper categories, and for most people, should be easier to find. IE: I > > wanna change how the bg looks...hmm, Appearance maybe? :) > > You are right, most categories are good already, but Misc and Advanced are > too vague for most people. IE: I want to change language. Is it in > Appearance? NO, is it in Extensions? No! advanced maybe? Not that one. Ill > just go to Misc... There is is :) > > Well, I actually put language it into misc in the first place. I just > suggest that some one _smart_ (with solving usability problems) > re-shuffle/add/remove categories to make a bit more sense. I agree that we may need to reorganize a bit. But, no organization will be totally fool-proof. Another option to ease finding the dialogs would be to keep a list of strings / keywords in the dialog and add a search box. rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO "enlightenment" please
On Sun, Nov 26, 2006 at 11:44:27PM -0600, Alberto wrote:
> But I do want to point out that a theme can has a many border styles as
> u can think of, so the data {item: "shade" "0"; } option could be used
> elsewhere. It just comes down to a matter of design and preferences.
> Personally I prefer to click on a border button and see the client
> window shade, instead of having to double click the titlebar.
> Unfortunately such signal does not exist.
I agree that we have a little more work to do on the customizability of
borders and their actions. The current implementation uses named parts
(e.event.*) to trap events that perform actions. In E, there is an
action set up that shade's a window when the user double clicks ont he
border's e.event.titlebar part. So, for a border button that shades, we
would need to add an e.event.shade part and attach the 'shade toggle'
action to *that*. We would also need some way for the user to disable
shading when double clicking on the titlebar (either in the generic
mouse actions dialog, or maybe as an option in a window behavior dialog
somewhere.
Another feature I'd like to see is user-configurable locations of border
buttons. *Most* themes are designed in a way that rearranging the
buttons and border icon would look just as good. So, possibly a dialog
that lets you pick between basic (windows-like, mac-like, theme-default,
etc) modes, with an advanced dialog to specify "close on the left,
maximize and shade on the right, but leave off the minimize button since
i never use it".
For this to be feasible, we'd have to break the buttons out into
separate edje groups, with SWALLOWS in the proper spots on the border.
(E.g. "e.swallow.buttons.left" and "e.swallow.buttons.right"). These
would swallow e_box's which would in lay out the requested buttons.
This does limit the flexibility on the part of the themer (no two
buttons could overlap in their boundaries for example), but gives much
more flexibility to the user. Really, there's no reason we couldn't
still allow the current style for themers that want it. We'd just need
to let the user know that certain border styles in the current theme
don't support button placement.
rephorm
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Theme: Japan 2007
On Sun, Nov 19, 2006 at 12:18:24PM +0100, phriedrich wrote: > Hi folks, > > after moving from Dresden to Leipzig I finally had some time to update > Japan2007 to the theme-changes. It is working so far, except a few > things: borders and window buttons still don't react. > So could someone please have a look at [1] and give me a hint what I > need to change? E looks for specially named parts to trigger these events on. In border.edc every EVENT_PART_MAP() needs the first param changed. Look at http://rephorm.com/files/dump/e_theme_map.txt under [[border]] [parts] for the new names (e.g. maximize -> e.event.maximize) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Feature Request: Option to lock ibar entries
On Sun, Nov 19, 2006 at 04:49:45PM +0900, Carsten Haitzler wrote: > On Wed, 15 Nov 2006 13:46:36 +1100 Daniel Kasak <[EMAIL PROTECTED]> > babbled: > > > A number of people here at work are 'losing' ibar entries by dragging > > them off the bar. I suppose I could make > > ~/.e/e/applications/bar/default/.order read-only ( haven't tested, but > > should work, right? ), but maybe we could have an option to simply lock > > it from changes / accidental removals? > > well that was the original idea - to remove items. but i can see how it can > lead to accidental removals easily. how about this - you have to drag the icon > a long way away (> 200 pixels) for it to be removed? sound good? > As long as the cursor changes in some way to indicate "dropping will remove this item" :) rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fw: Text color-classes in e17
On Sun, 12 Nov 2006 14:38:50 -0500 Christopher Michael <[EMAIL PROTECTED]> wrote: > Brian Mattern wrote: > > On Sun, 12 Nov 2006 03:40:17 -0500 > > Christopher Michael <[EMAIL PROTECTED]> wrote: > > > >> Brian Mattern wrote: > >>> On Sat, 11 Nov 2006 16:09:42 -0500 > >>> Christopher Michael <[EMAIL PROTECTED]> wrote: > >>> > >>>> This presents another issue in that what todo about precompiled > >>>> edj files ala get-e.org? Ship a seperate file with them? > >>>> Decompile/recompile? Etc, etc. > >>> they would just need to be recompiled. in general though, e17's > >>> usability trumps any concerns about supporting old theme > >>> binaries... > >>> > >> Of course, of course. Not saying that...just pointing out that even > >> if a given theme WAS current (ie: ok against current API), how to > >> determine avail. color classes? Decompile/recompile? Extra File? > >> (etc etc) > >> > >> "they would just need to be recompiled. in general though" .my > >> point pretty much :) Do we decompile/recompile at run-time to > >> determine avail. cc's ? IMHO, no...too much work (read: procs) > >> going on during startup. > >> > >> Which leaves?? > > > > Decompile / recompile at runtime makes no sense. I was suggesting > > adding a directory of color classes to the edj file format that gets > > created by edje_cc when compiling (similar to the font dir, spectra > > dir, etc). If there are OLD edj files that were created before this > > was added to edje they would need to be recompiled (once, then > > released again) or they wouldn't work. Simple as that. > > > > Given that most themes don't even include color classes yet, its > > not an issue. > > > > Or am I misunderstanding the 'issue' you're trying to point out? > > No, I believe that hits the nail on the head...it was I > misunderstanding your approach :) IMHO, this approach seems the way > to go. Not quite. As I mentioned in the earlier email, this approach still has some issues to work out. Currently all themed objects have a category associated with them (e.g. "base/theme/borders"). E first looks for a theme set on the full category, if none exists or the group requested isn't present in that file, it falls back to the 'parent' category (e.g "base/theme"), proceeding up the heirarchy and finally falling back to the default theme. So, the border could come from any of a number of themes set. With the current UI, the choice is limited to two themes, the currently selected and the default. (But at some later date, an advanced theme dialog could expose the rest of the functionality). So, now what if one of the themes implements the color classes and another doesn't. Until we attempt to load an object (cascading down until we find a theme that includes the requested group), we won't know which file we need to actually look in. Add to that the fact that the same color class could be used by different objects (e.g. module themes) and implemented in some but not in others... In other words "Will setting color class X to color Y have the intended effect?" is not an easy question to answer. rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fw: Text color-classes in e17
On Sun, 12 Nov 2006 03:40:17 -0500 Christopher Michael <[EMAIL PROTECTED]> wrote: > Brian Mattern wrote: > > On Sat, 11 Nov 2006 16:09:42 -0500 > > Christopher Michael <[EMAIL PROTECTED]> wrote: > > > >> This presents another issue in that what todo about precompiled > >> edj files ala get-e.org? Ship a seperate file with them? > >> Decompile/recompile? Etc, etc. > > > > they would just need to be recompiled. in general though, e17's > > usability trumps any concerns about supporting old theme binaries... > > > > Of course, of course. Not saying that...just pointing out that even > if a given theme WAS current (ie: ok against current API), how to > determine avail. color classes? Decompile/recompile? Extra File? (etc > etc) > > "they would just need to be recompiled. in general though" .my > point pretty much :) Do we decompile/recompile at run-time to > determine avail. cc's ? IMHO, no...too much work (read: procs) going > on during startup. > > Which leaves?? Decompile / recompile at runtime makes no sense. I was suggesting adding a directory of color classes to the edj file format that gets created by edje_cc when compiling (similar to the font dir, spectra dir, etc). If there are OLD edj files that were created before this was added to edje they would need to be recompiled (once, then released again) or they wouldn't work. Simple as that. Given that most themes don't even include color classes yet, its not an issue. Or am I misunderstanding the 'issue' you're trying to point out? rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fw: Text color-classes in e17
On Sat, 11 Nov 2006 16:09:42 -0500 Christopher Michael <[EMAIL PROTECTED]> wrote: > This presents another issue in that what todo about precompiled edj > files ala get-e.org? Ship a seperate file with them? > Decompile/recompile? Etc, etc. they would just need to be recompiled. in general though, e17's usability trumps any concerns about supporting old theme binaries... rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fw: Text color-classes in e17
On Sat, 11 Nov 2006 13:28:54 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > On Fri, 10 Nov 2006 14:24:53 -0500 "Chris Michael" > <[EMAIL PROTECTED]> babbled: > > > > Edje currently has an edje_color_class_list() function that > > > exports a list of cc's the current process knows about (from any > > > loaded edje objects). It *should* be possible to use this to > > > generate the list in the color class dialog. We probably need > > > some categorization though (maybe through namespacing the cc > > > names?) > > > > > > rephorm > > > > > The only problem with using edje_color_class_list to get the cc's > > is that, from what I found, if a part is not loaded > > currently...let's say a cc for check boxes (just for argument), > > then the edje_color_class_list function does not return it because > > the part is not loaded. What would be ideal is a function that can > > list all cc's defined in the theme, loaded or not. Originally, I > > had tried to use edje_color_class_list todo that color dialog list, > > but alas if the part isn't loaded, it never showed. > > which currently means loading every part in the groups. :( > Yeah, that is an issue. Another possibility would be to collect a list of color classes while compiling the edj and give access to that list. BUT, since most themes out there don't implement EVERYTHING (letting some stuff fall back to the default theme) it would be hard to know which colors classes will actually be available :( Will have to mull on this a bit. rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Text color-classes in e17
On Fri, Nov 10, 2006 at 11:48:58PM +0900, Carsten Haitzler wrote: > it's kind of a requirement of the theme to provide color and text classes > correctly- just as it is to provide swallow parts, labels, objects etc. as > required :) I don't think it should be. For instance, the default theme _only_ supports color classes on text. Winter however has a color class for the window border / pager border / etc. Due to the way the default theme is drawn, you can't easily change its color (unless we add 'hue rotation', 'hue setting' or other coloring modes to evas). So, I don't think its feasible to require all possible cc's. Edje currently has an edje_color_class_list() function that exports a list of cc's the current process knows about (from any loaded edje objects). It *should* be possible to use this to generate the list in the color class dialog. We probably need some categorization though (maybe through namespacing the cc names?) rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EDC Editor first try
On Thu, Nov 09, 2006 at 07:40:05PM +, [EMAIL PROTECTED] wrote: > > Brian writes: > > > > Just to follow up on this last bit here -- do you wish to > > > change the current edje gradient fill desc that relates to linear > > > grads? > > > > > > > I do, but have no idea when I'll get around to it. > > I understand.. unfortunately, it's an ever present problem > for all. :( > > U... Well, I actually rewrote the whole thing a while > back (when I was trying to find out where the grad transition issue > was coming from), and wrote everything to just use the general fill > (I also added all the other evas grad properties - spread, offset, > enabled the use of params, changed angles to be doubles, etc). > However, changing things to just use the general fill, would > break things. Sounds like what I had in mind. As for breaking things, its inevitable, and currently, the only use of edje grads (that I'm aware of) is in e17's grad bgs. So, not too much harm in breaking things. (I never actually documented the linear grad edc api because I figured it would change, so its unlikely that many people are using it) > > One last thing - A nice improvement for the grad dialog would > be to allow for lin grads at arbitrary angles, and to allow for the > use of the spread types.. One way to do this is similar to what the > Gimp has for letting you draw a grad, ie. you place the cursor at one > point on the preview and then at another, and this defines it - with > the spread mode determining what to do before/after those endpoints.. > Yeah, I had some of this in mind for an "advanced" version of the dialog. I'm not sure to what extent we want to go though, when most (i'm guessing) gradient bgs will be of the standard types. > Anyway.. When/if Carsten has time to get back to evas, and > everyone would prefer the use of the general fill for edje grads, > I can send the patch.. or if it's preferred to keep the current > interface for linear grads, I can modify it to be a bit simpler > internally, and add the other grad stuff as well. Send me the patch and I'll try to find time to review it and fix the edc generated by the grad dialog (if you haven't already done that). rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EDC Editor first try
On Thu, Nov 09, 2006 at 04:08:50PM +, [EMAIL PROTECTED] wrote: > > Just to follow up on this last bit here -- do you wish to > change the current edje gradient fill desc that relates to linear > grads? > I do, but have no idea when I'll get around to it. rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EDC Editor first try
On Wed, Nov 08, 2006 at 09:19:20PM +0100, DaveMDS wrote: > Hi all, > I'm working on an edc editor, something like glade but for the edje file. > I have just done all the parsing of the edc file and the inteface (for > now using gtk2). > Now I'm going to do the evas design window. > > Has someone just made some work on this? > Do you think it's useful? > > Thanks > DaveMDS > > PS: Some idea for the application name? my first choice is 'ertist' but > need suggestion. > There have been a few discussions in the past on how best to do an edje editor. (The old ebits editor was named 'etcher', so I always assumed we'd re-use that, but we don't have to. Frankly edje_editor is clear and straightforward enough. I had started playing with editor ideas a few years ago, but took a tack that proved itself to be the wrong one (using edje's internal data structures directly). We then started engrave as an edc parsing / editing library, to be used by any future editor. (However, its a total pain to keep it in sync with edje changes, and as such doesn't support anything that was added to edje over about a year ago). For another thread, see: Jan 17, 2006 Chady Kassouf [E-devel] [RFC] Edje GUI Editor Ideally, I'd like to see some sort of edc editing lib in edje itself that would be easier to keep in sync with edc changes. The next step to an editor is to write a simplified version of edje_calc() to be used in an editing environment. (e.g. only render the selected state, dont' respond to mouse events, maybe tween when a new state is selected...) On top of this we'd need the ability to select parts and add resize handles (some way of changing relative, offset and 'to' params with the mouse). Maybe also the ability to say "make this the min size of the part, and this the max". Anyway, its nice to see someone else picking this up. You should probably take a look at both ewl and etk and see if one or the other fits your needs before going with gtk. (just to keep it in the family). rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Priviledged Execution
On Mon, Nov 06, 2006 at 03:50:32PM -0500, Michael Jennings wrote: > On Monday, 06 November 2006, at 16:30:16 (+0100), > Essien Ita Essien wrote: > > > I'm just putting out feelers for ideas (a.k.a. best practices if > > such exist), for how to implement Priviledged Execution for > > Entrance_Edit_GUI > > Best practice: Don't do it. > > > The problem is that, the config file is /etc/entrance_config.cfg, > > which is protected file, but all users *can* run entrance_edit_gui > > for now. > > There is no point letting any user run entrance_edit_gui. Only root > should be able to run it. > > > Whats the best practice for implementing stuff like this in a GUI > > environment? > > Don't. It's too hard to audit the code. He still needs a solution to his problem. Namely "How do I let people configure entrance from a gui without having to touch the command line". One possibility is to have an "entrance" group that has write permissions to the config file. Then just require the users that want to run the config editor to be part of this group. rephorm. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch to allow caching of AC_ABSTRACT_SOCKET_TEST
On Thu, Nov 02, 2006 at 05:15:27PM +0100, Jeremy Lainé wrote: > Hi! > > I am currently running into problems when cross-compiling ecore, > because AC_ABSTRACT_SOCKET_TEST (ecore/m4/ac_abstract_socket.m4) > cannot be executed when cross-compiling and does not allow to be fed a > cached value. > > Attached is a patch that enables caching of the test result, so that > you can run for instance: > > ./configure ac_cv_abstract_socket=yes Would it be better to add a config option like --with-abstract-sockets=yes/no? That way it would show up in the configure help and not be a hidden feature. However, I'm not a packager, and I've never done cross compiles, so I'll leave it up to others to decide which is better. rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Newbie: let evas render to a memory buffer?
On Mon, Oct 30, 2006 at 12:31:51PM +0100, Joerg Plewe wrote: > Hi all! > > > > I'm new to this list and quite new to Enlightenment as well. > > > > While making up a software design, I'm interested whether it is possible to > let evas render into a memory buffer that can be read out afterwards? > > > > If so, how to? Create an evas with the buffer engine. The easiest is to use Ecore_Evas *ee = ecore_evas_buffer_new(width, height); Then you can grab the pixels with ecore_evas_buffer_pixels_get(ee); (the return is an array of 32 bit ARGB data, w*h long) rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/entrance xcomputerman
On Thu, Oct 26, 2006 at 04:14:21AM -0400, Enlightenment CVS wrote: > Author : xcomputerman > Module : apps/entrance > Log Message: > Begone, foul bugs. > > - Ecore_List *commands; > + Entrance_X_Session *exs = NULL; > + char *command = NULL; > + I thought Ecore_Desktop changed recently so that ecore_desktop_get_command() returns a list of commands. So, maybe your ecore was just out of date? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] DBUS Take 2
After spending some quality time with ecore_dbus and realizing how far from complete it is, I started to wonder "Why the hell do we have (the start of) a full reimplementation of dbus?" The low-level dbus API was designed to be as framework agnostic as possible. Shouldn't we just be wrapping dbus in an efl api (that handles hooking into the ecore main loop, etc) ala the glib/qt bindings? I'm starting to piece together some basic test code to this end, but just wanted to ask why this wasn't done in the first place? Was there a specific obstacle to integrating the two (haven't seen any yet, myself)? Or was this just an exercise in re-implementing a large body of code from a less-than-spectacularly documented spec? :) Anyway, if I get this working, I'd prefer to just have an e_dbus lib that lives outside of ecore (either in a git repo alongside the other dbus bindings, or elsewhere in e cvs). rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_DBus
On Tue, Oct 10, 2006 at 10:44:20PM +0900, Carsten Haitzler wrote: > On Sat, 23 Sep 2006 21:06:56 -0500 Brian Mattern <[EMAIL PROTECTED]> > babbled: > > > Is anyone out there currently using Ecore_DBus? > > > > /me sings "like a virgin... touched for the very first time!" > > (you get the idea) :) > So, I added a bit of support for doing things like providing objects and methods for others to use. However, there are still some fundamental types that haven't been implemented. And there has been no attempt to handle endianness (it currently hard codes the little endian flag in the header). In short, the marshal/unmarshal code needs a LOT of loving :) Is there any reason this needs to be in ecore proper? Maybe we should at least make it not build by default. But, do we have any sort of guidelines about what goes into ecore and what goes into a separate lib? As far as I can tell, the "no new deps" mandate for e17 has lead to a lot of stuff getting stuck in ecore that should really be in separate libraries. (The original point was so that we don't have to get other libraries 'release ready'. But, if we just stick large chunks in ecore, the same problem exists.) rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/edje raster
On Mon, Oct 09, 2006 at 11:00:45AM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : raster > Project : e17 > Module : libs/edje > > Dir : e17/libs/edje/src/lib > > > Modified Files: > edje_load.c > > > Log Message: > > > leaking spectrum colors man! :) > Yikes. Sorry about that one. :( - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment CVS committal
On Mon, Oct 02, 2006 at 12:40:33PM +, [EMAIL PROTECTED] wrote: > Ok, that will take care of your dialog previews and such... > *BUT* for some reason, when you hit "apply", it fails to do so. > No idea why -- that's some obscure e17 thing I know nothing about. > > If you want I can send you the diffs to edje and e17, > though I'm sure Brian intends to rewrite the edje grads a bit. > But again, I have no idea why nothing gets 'applied' to the > actual bg. I'll look at the bg dialog within the next couple of days (pretty busy with work atm. unfortunately). And I definitely plan on cleaning up the edje grads a bit. Just gotta find some time again. :) Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: sebastid sebastid
On Tue, Sep 26, 2006 at 05:57:33AM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : sebastid > Project : devs > Module : sebastid > > Dir : devs/sebastid > > > Removed Files: > id_dsa.pub info.txt > > > Log Message: > Gone. > Shit! Now who's going to clean up my typos? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore onefang
On Tue, Sep 26, 2006 at 01:16:13AM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : onefang > Project : e17 > Module : libs/ecore > > Dir : e17/libs/ecore/src/lib/ecore_desktop > > > Modified Files: > Makefile.am ecore_desktop_private.h > Removed Files: > ecore_desktop_xml.c > > > Log Message: > We already have an xml parser, we don't need another one. > In seb's defense, do we? The big comment at the start of of ecore_desktop_xmlame.c says "This is NOT a real XML parser." I always took that as meaning "stop-gap solution until we have a better (but still light) xml parser. You've said several times that it only does enough to support desktop files. If I throw it a desktop file that is valid xml but goes beyond the minimal amount that xmlame supports, will it work? rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_DBus
Is anyone out there currently using Ecore_DBus? After the notification spec was brought up, I decided to finally check ecore_dbus out. I've implemented a few of the missing things (receiving method calls, sending signals, getting the standard bus addresses from the environment, ...). In the course of doing this, though, I decided to break the api of ecore_dbus_new_method_call() in order to keep the parameters in a consistant ordering with some new methods (and with the spec). I still need to do some testing of the new code, so I probably won't commit for a few more days. But, the functions signature hasn't changed, just the ordering of some char *'s, so if anyone is currently using it, things will silently break. Just a heads up. rephorm. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
