[E-devel] [CFT] FreeBSD testers needed for e_module/net patch....
Hello,
Attached is a patch that will enable the net module to run on FreeBSD (I
hope). I am using it on 6.2-STABLE. I have no idea what other versions
it will be compatible with.
I am hoping a few people (running 6.2 or otherwise) might step up and
give it a whirl, and provide their feedback.
--
Regards,
Ravenlock
Index: e_modules/net/src/e_mod_config.c
===
RCS file: /var/cvs/e/e_modules/net/src/e_mod_config.c,v
retrieving revision 1.7
diff -u -r1.7 e_mod_config.c
--- e_modules/net/src/e_mod_config.c21 Feb 2007 02:13:35 - 1.7
+++ e_modules/net/src/e_mod_config.c23 Mar 2007 05:42:48 -
@@ -30,6 +30,7 @@
_config_devices_get(void)
{
Ecore_List *devs = NULL;
+#ifndef __FreeBSD__
FILE *f;
char buf[256];
char dev[64];
@@ -55,6 +56,23 @@
ecore_list_append(devs, strdup(dev));
}
fclose(f);
+#else
+ DIR *d = NULL;
+ struct dirent *dentry = NULL;
+
+ d = opendir("/dev/net");
+ if (!d) return NULL;
+
+ devs = ecore_list_new();
+ ecore_list_set_free_cb(devs, free);
+ while ((dentry = readdir(d)) != NULL)
+ {
+ if (strstr(dentry->d_name,".") == NULL)
+ecore_list_append(devs, strdup(dentry->d_name));
+ }
+ closedir(d);
+#endif
+
if (devs) ecore_list_goto_first(devs);
return devs;
}
Index: e_modules/net/src/e_mod_net.c
===
RCS file: /var/cvs/e/e_modules/net/src/e_mod_net.c,v
retrieving revision 1.12
diff -u -r1.12 e_mod_net.c
--- e_modules/net/src/e_mod_net.c 15 Mar 2007 13:27:12 - 1.12
+++ e_modules/net/src/e_mod_net.c 23 Mar 2007 05:42:48 -
@@ -1,28 +1,63 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=>5n-3f0^-2{2
+ */
#include
#include "e_mod_main.h"
#include "e_mod_net.h"
#include "e_mod_config.h"
#include "e_mod_configure.h"
+#ifdef __FreeBSD__
+#include
+#include
+#include
+#include
+#endif
typedef unsigned long bytes_t;
static void _bytes_to_string(bytes_t bytes, char *string, int size);
static void _cb_post(void *data, E_Menu *m);
static void _cb_configure(void *data, E_Menu *m, E_Menu_Item *mi);
+#ifdef __FreeBSD__
+static int get_ifmib_general(int row, struct ifmibdata *ifmd);
+
+static int
+get_ifmib_general(int row, struct ifmibdata *ifmd)
+{
+ int name[6];
+ size_t len;
+
+ name[0] = CTL_NET;
+ name[1] = PF_LINK;
+ name[2] = NETLINK_GENERIC;
+ name[3] = IFMIB_IFDATA;
+ name[4] = row;
+ name[5] = IFDATA_GENERAL;
+
+ len = sizeof(*ifmd);
+
+ return sysctl(name, 6, ifmd, &len, (void *)0, 0);
+}
+#endif
+
EAPI int
_cb_poll(void *data)
{
Instance *inst;
Config_Item *ci;
- FILE *f;
- char buf[256], popbuf[256], dev[64], tmp[100];
- int found = 0;
+ char buf[256], popbuf[256], tmp[100];
long bin, bout;
- bytes_t in, out, dummy = 0;
-
+ bytes_t in, out = 0;
+
inst = data;
ci = _config_item_get(inst->gcc->id);
-
+
+#ifndef __FreeBSD__
+ FILE *f;
+ char dev[64];
+ bytes_t dummy = 0;
+ int found = 0;
+
f = fopen("/proc/net/dev", "r");
if (!f) return 1;
@@ -44,14 +79,33 @@
}
fclose(f);
if (!found) return 1;
-
+#else
+ struct ifmibdata *ifmd;
+ int i, count, len;
+
+ len = sizeof(count);
+ sysctlbyname("net.link.generic.system.ifcount", &count, &len, (void *)0, 0);
+
+ ifmd = malloc(sizeof(struct ifmibdata));
+ for(i=1; i <= count; ++i)
+ {
+ get_ifmib_general(i, ifmd);
+ if (!strcmp(ifmd->ifmd_name, ci->device)) break;
+ }
+
+ in = ifmd->ifmd_data.ifi_ibytes;
+ out = ifmd->ifmd_data.ifi_obytes;
+
+ free(ifmd);
+#endif
+
bin = in - inst->in;
bout = out - inst->out;
bin = bin / 0.5;
bout = bout / 0.5;
inst->in = in;
inst->out = out;
-
+
if (bin <= ci->limit)
edje_object_signal_emit(inst->o_net, "e,state,receive,idle", "e");
else
-
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 3/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Now that would be good indeed... What exactly would one need > from ewl or etk for this? > One'd also need to come up with a format for decribing such > gui-interfaces, one that would have the concepts of toolkit widget > types, and edje groups... > Any suggestions??? :) werkt put together an app called ewler that did a lot of the serialization necessary for describing EWL widgets. It hasn't been updated in a while, so I'm not sure if it works still. Some combination of this with an edje layout application could provide a basic framework. > It'd be good to see a real example of this combined use > of toolkit-widgets + custom-edje-widgets in an app like "rage" or > "entrance" or "elicit" or whatever. src/bin/ewl_embed_test.c shows how to do this. It's a simple application, but it does show how the interaction can work. > I also think, as I mentioned before, that it would be nice > if the toolkits allowed for 'widgets' obtained via run-time loadable > libs (rather than requiring included headers for custom/derived > widgets), ie. the 'gui-module' kind of thing I mentioned earlier. > Why? Well, I think the 'epplet' kinds of things that eg. > some of e17's modules now give would be nice to have *widely available* > and *easily added* in gui's - and I just don't see why an app should > need to know eg. internal headers for a "clock" gizmo? (maybe just > certain simple interfaces that such a thing might want to export..??). > This might be too unstructured, and there may be better ways.. > but just thought I'd mention it. :) I don't think this kind of gizmo support belongs directly in the toolkit library. It sounds more like a module loading wrapper around widgets that don't export any API calls. An external library, lets call it ewl-candy for now, could do this by defining a module hooks and simply returning an Ewl_Widget. That widget could then be placed inside of any EWL container. The library itself could be very simple, but provide some basic gizmos for re-use. These widgets could also be an extended widget type that exports additional interfaces beyond the base Ewl_Widget class. - 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.....
Thanks to all who responded. I have a much better understanding now. :) -Ravenlock On 03/16/2007 07:17, 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)? > > Also, how about this one: > > * desktop flip animations need to allow control over accel/decel and > have a better ui - add wobble and controls etc. etc. > > Seems to me this is done? There are controls for type of animation and > its speed, via Config -> screen -> virtual desktop. Is that not what > this item is referring to? I don't understand "wobble". That a new > transistion type? > > And finally this one: > > * 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. > > Thanks. :) > -- Regards, Ravenlock - 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] SDL Engine in windows?
Hello, I have a question regarding the resent SDL Engine updates. Would the engine allow evas on windows? I do not use windows but I do have to program apps for it and it would be really cool to use evas + edje and even have some portability. I know there maybe more issues getting evas etc to run on windows just wondering if it was a step closer. Thanks Frederick - 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.
Simon wrote: > Actually, one thing that could be really cool would be a tool > like Glade, but that would allow us to build interfaces made of > Edje objects and Etk (or Ewl) widgets. For example, for Entrance, > we could have the main interface still be an Edje object but we > could replace the entry/buttons by themed Etk widgets. With the > tool, we could place the widgets wherever we want in the interface > (no fixed layout anymore). Same for elicit, the spinners could be > spinners from Etk (just an example). The apps will look exactly > the same, and will still be as themable as before, but it would > combine the advantages of the both libraries (Edje and Etk): > the high themability of Edje and the ease of use of Etk (there > would be no need to reimplement the behavior of an entry or of > a spinner in the code, there would natively be keyboard-navigation > between the different widgets of the interface, ...). I'm not sure > I'm clear here, but I really think it would be really nice thing > to have. Now that would be good indeed... What exactly would one need from ewl or etk for this? One'd also need to come up with a format for decribing such gui-interfaces, one that would have the concepts of toolkit widget types, and edje groups... Any suggestions??? :) Nathan wrote: > Use what you like. If you are developing an application that > a toolkit is sufficient for, then use a toolkit. If you are > developing something with a highly custom interface, then use > Edje. There are points in between where you can mix the two > fairly easily. For example, using a toolkit to provide file > chooser dialogs or standard widgets, or creating a custom > theme for the toolkit to make your application look a specific > way. It'd be good to see a real example of this combined use of toolkit-widgets + custom-edje-widgets in an app like "rage" or "entrance" or "elicit" or whatever. I also think, as I mentioned before, that it would be nice if the toolkits allowed for 'widgets' obtained via run-time loadable libs (rather than requiring included headers for custom/derived widgets), ie. the 'gui-module' kind of thing I mentioned earlier. Why? Well, I think the 'epplet' kinds of things that eg. some of e17's modules now give would be nice to have *widely available* and *easily added* in gui's - and I just don't see why an app should need to know eg. internal headers for a "clock" gizmo? (maybe just certain simple interfaces that such a thing might want to export..??). This might be too unstructured, and there may be better ways.. but just thought I'd mention it. :) jose. - 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.
Brian wrote: > 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. I'd have to disagree with this.. there are many reasons why, but again just from the point of view of 'initial effort', no matter what you might be writing, unless you are really comfortable with directly using evas+edje+ecore, it may be a difficult way to start, wheras many are likely far more comfortable with a more traditional "gui-toolkit" approach, its concepts, etc. Furthermore, and this was something that was on my mind from the start, if indeed the e-toolkits are well designed enough that they can allow you to override theming of built-in stuff, (as well as create custom widgets+theme), then it'll be easier to slowly work the app into further edje-based customization as the writer becomes more familiar with things. Eventually, more and more inovative 'mixes' will emerge, but I think you and Simon may be a bit too familiar with edje&things, and forget that not everyone else is similarly so. :) > 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. Well, that was one of the things I'd hoped to see further discussion on by the toolkit authors.. there are many interesting aspects that can be explored here, both at the toolkit level and above&below that. jose. - 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 3/22/07, Peter Parkanyi <[EMAIL PROTECTED]> wrote: > > Which one should one use when they want it to embed the widgets into an edje > interface? Etk or Ewl? Now you're leaving the pseudo-technical discussion and delving into politics. I would advocate EWL and Simon would advocate ETK, this is going to come down to who you ask. > The other question I have: Why does two toolkits like these co-exist? Will ETK > replace EWL? I was told that this isn't the case. I don't quite understand > the reason, though. No, ETK is not an EWL replacement, they are independent development efforts. There are mailing list archives that cover this topic thoroughly, feel free to search those if you really want to know the reasons. > Wasn't ETK made to provide an API similar to GTK's, so the porting would be > easier? And now you say, we should do Edje instead. Use what you like. If you are developing an application that a toolkit is sufficient for, then use a toolkit. If you are developing something with a highly custom interface, then use Edje. There are points in between where you can mix the two fairly easily. For example, using a toolkit to provide file chooser dialogs or standard widgets, or creating a custom theme for the toolkit to make your application look a specific way. > Btw, where can I find an Edje how-to, which describes not only the .edc files, > but the linking to the application, too? I don't know of any good sources for this atm. The Edje or EFL cookbook documents in CVS might cover this somewhat, but looking at existing apps is probably the easiest way to pick it up. Nathan - 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/emotion tilman
On 3/22/07, Sebastian Dransfeld <[EMAIL PROTECTED]> wrote:
> > + xine_plugins=$(pkg-config --variable=plugindir libxine)
[...]
> libxine's pkgconfig does not contain plugindir, at least not here :(
neither here:
cat /usr/lib/pkgconfig/libxine.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
[...]
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
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] forecast's popup, to popup on a click (configurable)...
В чт, 2007-03-22 в 09:26 -0500, Ravenlock написа: > On 03/21/2007 01:05, Виктор Кожухаров wrote: > > В вт, 2007-03-20 в 22:07 -0500, Ravenlock написа: > >> Hello, > >> > >> I, just this evening, started using the forecast module. I like it very > >> much. > >> > >> However, I find that the popup... popping up on a hover is terribly > >> annoying. Its annoying for me because I like to keep it in the upper > >> right corner of my screen. Being there, every time I minimize a > >> window... I am then hovering over it, and it pops up. :( > >> > >> So I wanted to have an option to have the popup window popup on either a > >> mouse in or a mouse down. > >> > >> The attached patch alters the config panel, and provides a way to > >> disable the "popup on hover". If "popup on hover" is unchecked, the > >> popup will appear on a mouse down, and stay pinned. A second mouse down > >> will hide it. > >> > >> PLEASE NOTE: > >> This patch also changes the default popup behavior to popup on the mouse > >> down. This is by design. My argument for doing it this way is... The > >> original was not a popup on *hover*... but popup immediately on a mouse > >> in. This meant that if you just passed over it carelessly... it popped > >> up. That bothered me too. A timer, to create a short "hover" delay > >> would be necessary to make the hover work properly, imho. > >> > >> I hope someone finds this useful. :) > > Thanks. I'm going to take a look at it. However, the default behavior is > > going to stay, so I'll have to change the logic of the patch to turn off > > the popup at mouse in, instead of turning it on. And an immediate popup > > at mouse in is important, since people tend to want information > > immediately, instead of having to wait for a timer to time out :) > > > > Having never worked on a 'module' before. I realize after a second > glance that I forgot some init code. Would you like me to provide an > updated patch? Its probably the same code you would wind up adding to > make sure the module exhibits the original default behavior. > > Thanks. > Sure. Patches are always welcome :) > > p.s. And practice your mouse control, it sounded like you triggered the > > popup one too many times :) > > > > > > > > > > - > > 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 > > -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото - 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/emotion tilman
Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : tilman > Project : e17 > Module : libs/emotion > > Dir : e17/libs/emotion > > > Modified Files: > configure.in > > > Log Message: > use pkgconfig to detect libxine. untested :o > > === > RCS file: /cvs/e/e17/libs/emotion/configure.in,v > retrieving revision 1.40 > retrieving revision 1.41 > diff -u -3 -r1.40 -r1.41 > --- configure.in 21 Mar 2007 17:30:09 - 1.40 > +++ configure.in 22 Mar 2007 16:25:10 - 1.41 > @@ -99,11 +99,11 @@ > [enable_xine=$enableval],[enable_xine=auto]) > HAVE_XINE="no" > if test "$enable_xine" != "no" ; then > - AC_PATH_GENERIC(xine, 1.1.1, [HAVE_XINE="yes"]) > + PKG_CHECK_MODULES(XINE, [libxine >= 1.1.1], [HAVE_XINE="yes"]) > > if test "$HAVE_XINE" = "yes" ; then > requirements="$requirements libxine" > - xine_plugins=`$XINE_CONFIG --plugindir` > + xine_plugins=$(pkg-config --variable=plugindir libxine) > AC_SUBST(xine_plugins) > fi > fi libxine's pkgconfig does not contain plugindir, at least not here :( Sebastian - 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 Thursday 22 March 2007 16:36:46 Simon TRENY wrote: > On Thu, 22 Mar 2007 09:59:02 -0500, > > Brian Mattern <[EMAIL PROTECTED]> wrote : > > 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. Which one should one use when they want it to embed the widgets into an edje interface? Etk or Ewl? The other question I have: Why does two toolkits like these co-exist? Will ETK replace EWL? I was told that this isn't the case. I don't quite understand the reason, though. Wasn't ETK made to provide an API similar to GTK's, so the porting would be easier? And now you say, we should do Edje instead. Btw, where can I find an Edje how-to, which describes not only the .edc files, but the linking to the application, too? Peter - 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, 22 Mar 2007 09:59:02 -0500, Brian Mattern <[EMAIL PROTECTED]> wrote : > 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. Exactly what I meant :) Btw, the glade-like lib is enhance, emphasis is the mpd client (audio player). Actually, one thing that could be really cool would be a tool like Glade, but that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets. For example, for Entrance, we could have the main interface still be an Edje object but we could replace the entry/buttons by themed Etk widgets. With the tool, we could place the widgets wherever we want in the interface (no fixed layout anymore). Same for elicit, the spinners could be spinners from Etk (just an example). The apps will look exactly the same, and will still be as themable as before, but it would combine the advantages of the both libraries (Edje and Etk): the high themability of Edje and the ease of use of Etk (there would be no need to reimplement the behavior of an entry or of a spinner in the code, there would natively be keyboard-navigation between the different widgets of the interface, ...). I'm not sure I'm clear here, but I really think it would be really nice thing to have. Simon > > 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 > - 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] E and gui-toolkits.
Simon writes: > Yes, you can have additionnal widgets (clocks, rss, whatever, ...) > in loadable libraries. In fact, you can build external widgets > because you have access to all the methods for this in the Etk > headers. Sure. But the questions is really more of wether the toolkits themselves should provide a 'simple mechanism' for making these available in a 'standard' way (as well as a repo of common such that it might want to include). > > If e can have nearly as many apps written in its toolkits > > as there are now for gtk.. then I'd say that alone would be great > > achievement! > 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 They aren't as known or as simple to use for building large or common stuff, as more 'standard' gui-toolkits.. they require much more initial effort, time, etc.. IF you do have the initiative, the time, the desire, the creative drive.. to really want to make something "completely different", THEN yes that would be the way to go from the start. For many others, it might just not be worth it and instead opt to use more familiar tools and concepts.. especially if the built-in theming is already quite satisfactory. > differently. But some apps can't indeed be done really differently > (for example, an Email client or a FTP client in Gnome/Kde/E will > always look the same, we can't be really innovative here). How do you know? Sure you can, you just have to The point isn't wether one can or cannot make some things really new, better, different.. nor wether one should or should not do it. It's letting people make those decisions themselves by giving them the ability to have the 'best of both worlds' if they so desire. :) jose. - 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] forecast's popup, to popup on a click (configurable)...
On 03/21/2007 01:05, Виктор Кожухаров wrote: > В вт, 2007-03-20 в 22:07 -0500, Ravenlock написа: >> Hello, >> >> I, just this evening, started using the forecast module. I like it very >> much. >> >> However, I find that the popup... popping up on a hover is terribly >> annoying. Its annoying for me because I like to keep it in the upper >> right corner of my screen. Being there, every time I minimize a >> window... I am then hovering over it, and it pops up. :( >> >> So I wanted to have an option to have the popup window popup on either a >> mouse in or a mouse down. >> >> The attached patch alters the config panel, and provides a way to >> disable the "popup on hover". If "popup on hover" is unchecked, the >> popup will appear on a mouse down, and stay pinned. A second mouse down >> will hide it. >> >> PLEASE NOTE: >> This patch also changes the default popup behavior to popup on the mouse >> down. This is by design. My argument for doing it this way is... The >> original was not a popup on *hover*... but popup immediately on a mouse >> in. This meant that if you just passed over it carelessly... it popped >> up. That bothered me too. A timer, to create a short "hover" delay >> would be necessary to make the hover work properly, imho. >> >> I hope someone finds this useful. :) > Thanks. I'm going to take a look at it. However, the default behavior is > going to stay, so I'll have to change the logic of the patch to turn off > the popup at mouse in, instead of turning it on. And an immediate popup > at mouse in is important, since people tend to want information > immediately, instead of having to wait for a timer to time out :) > Having never worked on a 'module' before. I realize after a second glance that I forgot some init code. Would you like me to provide an updated patch? Its probably the same code you would wind up adding to make sure the module exhibits the original default behavior. Thanks. > p.s. And practice your mouse control, it sounded like you triggered the > popup one too many times :) > > > > > - > 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 -- Regards, Ravenlock - 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, 22 Mar 2007 11:00:59 +0100 Simon TRENY <[EMAIL PROTECTED]> wrote: > On Thu, 22 Mar 2007 04:13:35 GMT, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote : > > > Simon writes: > > > > > > In a slightly different vein.. Is there something like > > > > the equivalent of e17's modules for the gui-toolkits -- does > > > > something like that even make sense? > > > I'm not sure I understand what you mean here. You can have > > > loadable widgets from a library, but there is no such things as > > > "modules" (i.e. plugins that may change the behavior of an Etk > > > apps). It may be a good idea, but I don't really see a use for > > > this for now. > > > > Well, let's say 'gui-modules' as loadable libs that would > > provide additional interesting (but possibly somewhat more specific) > > functionality than buttons/menus/... For example, et's say we have > > an "rss" feed module, or a "wether/forecast" one, or just a "clock", > > ... and that these could be embedded in normal toolkit widgets (in > > a menu or bar or whatnot). > > Yes, you can have additionnal widgets (clocks, rss, whatever, ...) in > loadable libraries. In fact, you can build external widgets because > you have access to all the methods for this in the Etk headers. I think this is what raster eventually wants with gadgets. To embed them in lots of interesting places apart from shelves. signature.asc Description: PGP signature - 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, 22 Mar 2007 04:13:35 GMT, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote : > > From Nathan's, Simon's, and Dan's replies, it seems that > both ewl and etk do have mechanisms for allowing app-specific > theme overriding of the toolkit widgets, and in fairly general > ways. Wow. > So, one could write an app, to start with, that uses only > the toolkit themes, and if desired one could then extend this to > allow for further app-specific mods. Best of both worlds. > > Ok, could one take say raster's "rage" and do this? > ie. could it be written with ewl/etk to use only (or mostly) the > toolkit widgets/themes and then extend it to duplicate whatever > its current theming? What about the same for say, "entrance"? Rage could be written quite easily with Etk (and Ewl I think), it would only require to implement a new container for the list of medias. But the thing is, there is no point of writting Rage with Etk/Ewl rather than directly with Edje. For Entrance, it's a bit more complicated since it doesn't have a fixed layout. With Etk/Ewl, you can theme each widgets individually, but you can't "theme" the layout. With Etk, you can still use glade + enhance to make the layout a bit themable, but it would never be as flexible as with Edje. > Simon writes: > > > > In a slightly different vein.. Is there something like the > > > equivalent of e17's modules for the gui-toolkits -- does something > > > like that even make sense? > > I'm not sure I understand what you mean here. You can have loadable > > widgets from a library, but there is no such things as > > "modules" (i.e. plugins that may change the behavior of an Etk > > apps). It may be a good idea, but I don't really see a use for this > > for now. > > Well, let's say 'gui-modules' as loadable libs that would > provide additional interesting (but possibly somewhat more specific) > functionality than buttons/menus/... For example, et's say we have > an "rss" feed module, or a "wether/forecast" one, or just a "clock", > ... and that these could be embedded in normal toolkit widgets (in > a menu or bar or whatnot). Yes, you can have additionnal widgets (clocks, rss, whatever, ...) in loadable libraries. In fact, you can build external widgets because you have access to all the methods for this in the Etk headers. > > Nathan writes: > > > This seems like a higher level function, like the KParts you mention > > below. > > Ummm... Yeah, but possibly something more 'lightweight' would > be good as well. > > I just took a quick look at "kparts", this seems to be a > mechanism for allowing functionality that some apps may have to be > shared by others. > It seems to require that 'part' to be given as a loadable > shared lib with certain kinds of interfaces that are known, and > the rest (gui controls) to be specified in an xml file in certain > ways. > This is something that doesn't seem to need a source app > at all, but likely obtained that way from existing ones. It also > seems to me that this kind of thing could be achieved via a > sufficiently extended notion of a 'vfs'. > Anyway... it does seem to be a useful idea. > > > Simon writes: > > > There is something I'd like to discuss here although I'm not sure > > it's really the right place to do so.. Since Etk and Ewl have begun > > to be usable enough, there has been a lot of new apps using one of > > these too. The thing is, too often those apps only copy existing > > apps and I just don't think this the right way. A lot of these apps > > would have been a lot better if they hadn't used a toolkit but if > > they had used directly Edje (and using Etk/Ewl only for the config > > dialogs)... > > Ummm.. I know what you're trying to say.. But there are > several sides to this. One is that most people will find it MUCH > easier to use a toolkit, and that seems to me to be the way to start > unless you want a mostly stand-alone app, and are very good with edje. > If e can have nearly as many apps written in its toolkits > as there are now for gtk.. then I'd say that alone would be great > achievement! 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 quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things differently. But some apps can't indeed be done really differently (for example, an Email client or a FTP client in Gnome/Kde/E will always look the same, we can't be really innovative here). > > If indeed one can extend ewl/etk in the ways you mention, > then one could later optionally extend the theming and/or widgetry > to be as unique as desired - hence allowing for both app-unique > and toolkit-common 'look&feel' for a large number of apps that > people may be inclined to write. Actually, w
Re: [E-devel] E and gui-toolkits.
On Wed, 21 Mar 2007 22:41:28 -0400, dan sinclair <[EMAIL PROTECTED]> wrote : > > On 21-Mar-07, at 7:10 PM, Simon TRENY wrote: > > In Etk, as in Ewl I think, you can change the theme of a specific > > widget or change globally the theme used by all the widgets. > > About custom widgets, it's indeed possible to build your own widget > > directly in the app's code, the only difficulty here will be > > the themability: either you use theme-parts from existing widgets > > and there will be no problem, or you use your own theme-file for > > this widget but it may look wrong with some Etk/Ewl themes. > > > > Ewl will allow you to specify the .edj file on a per widget basis if > desired. Each widget has a /file along with a /group key that can be > set. There is the same system in Etk as well. > 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
