Re: [E-devel] how build debian packages ?
Vlad Alyukov wrote: problem description: configure scripts not create debian/changelog dpkg-buildpackage -rfakeroot [skip] dpkg-parsechangelog: error: cannot open ./eet/debian/changelog to find format: No such file or directory dpkg-source: error: syntax error in parsed version of changelog at line 0: empty file how generate this file? A temporary solution I found is to copy changelog.in in changelog cp debian/changelog.in debian/changelog an run again 'dpkg-buildpackage -rfakeroot' -- Valéry Febvre --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] how build debian packages ?
VF == Valéry Febvre writes: Hello, Valéry! /Thu, 29 Dec 2005 11:04:20 +0100/ you wrote: VF Vlad Alyukov wrote: problem description: configure scripts not create debian/changelog dpkg-buildpackage -rfakeroot [skip] dpkg-parsechangelog: error: cannot open ./eet/debian/changelog to find format: No such file or directory dpkg-source: error: syntax error in parsed version of changelog at line 0: empty file how generate this file? VF A temporary solution I found is to copy changelog.in in changelog VF cp debian/changelog.in debian/changelog VF an run again 'dpkg-buildpackage -rfakeroot' variable VERSION not define show errors: dpkg-buildpackage: source package is eet dpkg-buildpackage: source version is @[EMAIL PROTECTED] dpkg-buildpackage: source changed by Sytse Wielinga [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp /usr/bin/make distclean make[1]: Entering directory `/var/ftp/cvs/e17/libs/eet' make[1]: *** Нет правила для сборки цели `distclean'. Останов. make[1]: Leaving directory `/var/ftp/cvs/e17/libs/eet' make: [clean] Ошибка 2 (игнорирована) dh_clean dh_clean: Compatibility levels before 4 are deprecated. dpkg-source -b eet dpkg-source: warning: source directory `./eet' is not sourcepackage-upstreamversion [EMAIL PROTECTED]@' dpkg-source: building eet in [EMAIL PROTECTED]@-1.tar.gz dpkg-source: building eet in [EMAIL PROTECTED]@-1.dsc debian/rules build and create wrong files name: [EMAIL PROTECTED]@-1.dsc [EMAIL PROTECTED]@-1_i386.changes [EMAIL PROTECTED]@-1.tar.gz how fix this? -- Vlad Alyukov --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] how build debian packages ?
Vlad Alyukov wrote: VF == Valéry Febvre writes: Hello, Valéry! /Thu, 29 Dec 2005 11:04:20 +0100/ you wrote: VF Vlad Alyukov wrote: problem description: configure scripts not create debian/changelog dpkg-buildpackage -rfakeroot [skip] dpkg-parsechangelog: error: cannot open ./eet/debian/changelog to find format: No such file or directory dpkg-source: error: syntax error in parsed version of changelog at line 0: empty file how generate this file? VF A temporary solution I found is to copy changelog.in in changelog VF cp debian/changelog.in debian/changelog VF an run again 'dpkg-buildpackage -rfakeroot' variable VERSION not define show errors: dpkg-buildpackage: source package is eet dpkg-buildpackage: source version is @[EMAIL PROTECTED] dpkg-buildpackage: source changed by Sytse Wielinga [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp /usr/bin/make distclean make[1]: Entering directory `/var/ftp/cvs/e17/libs/eet' make[1]: *** Нет правила для сборки цели `distclean'. Останов. make[1]: Leaving directory `/var/ftp/cvs/e17/libs/eet' make: [clean] Ошибка 2 (игнорирована) dh_clean dh_clean: Compatibility levels before 4 are deprecated. dpkg-source -b eet dpkg-source: warning: source directory `./eet' is not sourcepackage-upstreamversion [EMAIL PROTECTED]@' dpkg-source: building eet in [EMAIL PROTECTED]@-1.tar.gz dpkg-source: building eet in [EMAIL PROTECTED]@-1.dsc debian/rules build and create wrong files name: [EMAIL PROTECTED]@-1.dsc [EMAIL PROTECTED]@-1_i386.changes [EMAIL PROTECTED]@-1.tar.gz how fix this? To fix this, you can delete the line: debian/changelog in the configure.in file. It's at the end of file in MACRO AC_OUTPUT() -- Valéry Febvre --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Design idea for the configuation panel (aka my two cents)
Good Day to you all e-devs and thank you for your great job =) As you can understand from the subject of this e-mail I'm here to suggest you a design idea for the configuration panel, take it or leave it, it's up to you. Obviously *anyone* can post impressions and improvements of this idea if they like. Now, i was wandering if you plan to make the configuration panel and all the sub-options one monolithic window... it could be nicer to have something as will follow, rather than to have many windows open like in this screenie: http://www0.get-e.org/Screenshots/User_Submitted/_images/dialogs.png -- Of course it is not compulsory to have all of them open at one time, but this is not the main point. The point is to have *always* one piece and not to have a second (third, fourth and so on..) window opened for the config option one choses to open. To let you understand better i'll use an example: My idea in example: #1- the config panel opens like it does now from the main menu, and opens the configuration panel main window. #2- when you click on a configuration item (let's say background settings) , that slides off on the right of the main window (pretty much like the eclair's cover thing) and presents you the configuration you have chosen. (let's say background settings) in basic mode. #2a- advanced mode might have few lines explaining the user what's all about. #3- if one leaves the background settings before he applied the change , there should be a warning save the changes? and the likes. #4- when one leaves the current config dialogue for another, then the first slides back in and the second slides off afterwards. there might be room for great eye-candy here, like eg: transparency or fade in fade out. #5- if one clicks on the advanced settings the whole pc must implode. #6 -whatever you like, i'm out of ideas. best regards and thank you again for the whole E project =) ps: the txt attached is the log of the #edevelop chat where this started.-- Callea Gaetano Andrea[EMAIL PROTECTED] CGA hi all,i was wandering if you plan to make the config panel and all the sub-options one monolitic piece of software... it could be nicer than to have many windows open i have an idea for this. tziOm CGA - tellus CGA well , you could have the config panel opne as it does now but when you click on a config thingy it should open a slide one the right (most likely entrance does with the sessions) and in there you would have , let's say, the module config dialogue CGA have i been clear? sorry for my enlgish divVerent CGA: you are probably thinking of something similar to Apple's System Preferences dialog? Just that one would see both the possible setting types and the settings at once CGA divVerent, i don't know the Apple's one but i like the KDE one, anyway i'm not suggesting to make something like Kontrol center devilhorns CGA: but in a way, you are :) lol CGA i only think that iot should be less fragmentated divVerent yes, kcontrol... but without a hierarchical list on the left side perhaps CGA devilhorns, oh... ok :P divVerent or like Firefox' configuration dialog devilhorns CGA: well, how is it fragmented ? divVerent well, I happen to like it opening a window for each setting type... so you can have multiple open at once... devilhorns exactly CGA devilhorns, like it is now, you open many windows... oh ok i likethe opposite, one window at the time :P devilhorns CGA: then only open one window at a time, silly man CGA anyway was just my opinion devilhorns you do have a choice :) CGA lol divVerent he cannot divVerent Configuration panel is already window #1 divVerent ;) devilhorns har har CGA i might have expressed myslef badly sine enlgish is not my lang. let me think about it and make a collage with png... devilhorns CGA: ok, but I'm pretty sure I see what you're going for divVerent you mean like eclair's playlist? CGA yes tziOm I tend to agrea with CGA tziOm closing windows is not my favorite sport tziOm atleast not with laptop tziOm kbd navigation would also be simpler CGA and in there you could even put some infoes about the advanced settings devilhorns tziOm: think there is a binding to close current window * CGA rolls up and reads you all divVerent but there is no binding for click this button and close this window immediately... not that there should be one devilhorns CGA: my suggestion...start a discussion about it on the mailing list CGA k devilhorns let people toss around different ideas devilhorns and any devs currently sleeping can read it when they wake, and add their 5 cents divVerent but still... I have to look through the different eap icon sets... the current icon of entangle that I have looks like it is for tetris, not for a ibar/menu configuration dialog tziOm would be nice if every idea was graphical.. spend some time with gimp.. cut and paste devilhorns tziOm: yea, that might help explain it better CGA that's what i'm going to do tziOm nice
[E-devel] much better smart maximization algorithm
Hi all, Some weeks ago it was a conversation about how e17 does smart maximization of a window. It was proposed to introduce some user defined configuration options, to let e17 to know the area of the desktop it can use for maximization. However, I think, Rasterman proposed much better solution. The idea was, that each gadget should hint if it allows to maximize over it. Please find the *.tar.gz archive attached. Also this archive can be found via the following link : http://rose.inf.unibz.it/~struk/e17/e.patch.tar.gz. This archive contains some patches to e and e_modules. First it touches e itself. It introduces E_GADMAN_POLICY_ALLOW_OVERLAP flag. This flag can be used to set the way gadget influences the maximization of a border. Second, it patches all the standard E modules ( battery, cpufreq, start, etc ) and introduces a configuration menu option which allows to set E_GADMAN_POLICY_ALLOW_OVERLAP flag. If E_GADMAN_POLICY_ALLOW_OVERLAP flag is set for the gadget, then the gadget is not taken into account when the maximized border computed. And vice versa, if it is not set the gadget is taken into account computing maximized border. The following code shows how this option can be set/unset: E_Gadman_Policy pol; ... pol = ; if( gadget-conf-allow_overlap == 0 ) pol = ~E_GADMAN_POLICY_ALLOW_OVERLAP; else pol |= E_GADMAN_POLICY_ALLOW_OVERLAP; e_gadman_client_policy_set( face-gmc, pol ); ... Please refer to the modules code, after applying the patch, to see how things really works ::)) Finally, the archive contains some patches for extra modules in e_modules. The 'calendar' and the 'monitor' modules are patched to support the mechanizm described above. As a conclusion, I think, this patch partialy solves the 4th case of the maximization TODO. Thanks Aleksej -- Aleksej StrukMaster Degree StudentFree University of Bozen-BolzanoFaculty of Computer Science phone: +39-0471-061749cell phone: +39-3204627049 [EMAIL PROTECTED] [EMAIL PROTECTED] - http://www. e.patch.tar.gz Description: GNU Zip compressed data
[E-devel] Re: much better smart maximization algorithm
Hi again, Unfortunately I forgot to mention one thing. e.patch.tar.gz also contains e_mod_config.h and e_mod_config.c files for the start module. Sorry for inconvinience. Aleksej.On 12/29/05, Aleksej Struk [EMAIL PROTECTED] wrote: Hi all, Some weeks ago it was a conversation about how e17 does smart maximization of a window. It was proposed to introduce some user defined configuration options, to let e17 to know the area of the desktop it can use for maximization. However, I think, Rasterman proposed much better solution. The idea was, that each gadget should hint if it allows to maximize over it. Please find the *.tar.gz archive attached. Also this archive can be found via the following link : http://rose.inf.unibz.it/~struk/e17/e.patch.tar.gz. This archive contains some patches to e and e_modules. First it touches e itself. It introduces E_GADMAN_POLICY_ALLOW_OVERLAP flag. This flag can be used to set the way gadget influences the maximization of a border. Second, it patches all the standard E modules ( battery, cpufreq, start, etc ) and introduces a configuration menu option which allows to set E_GADMAN_POLICY_ALLOW_OVERLAP flag. If E_GADMAN_POLICY_ALLOW_OVERLAP flag is set for the gadget, then the gadget is not taken into account when the maximized border computed. And vice versa, if it is not set the gadget is taken into account computing maximized border. The following code shows how this option can be set/unset: E_Gadman_Policy pol; ... pol = ; if( gadget-conf-allow_overlap == 0 ) pol = ~E_GADMAN_POLICY_ALLOW_OVERLAP; else pol |= E_GADMAN_POLICY_ALLOW_OVERLAP; e_gadman_client_policy_set( face-gmc, pol ); ... Please refer to the modules code, after applying the patch, to see how things really works ::)) Finally, the archive contains some patches for extra modules in e_modules. The 'calendar' and the 'monitor' modules are patched to support the mechanizm described above. As a conclusion, I think, this patch partialy solves the 4th case of the maximization TODO. Thanks Aleksej -- Aleksej StrukMaster Degree StudentFree University of Bozen-BolzanoFaculty of Computer Science phone: +39-0471-061749cell phone: +39-3204627049 [EMAIL PROTECTED] [EMAIL PROTECTED] - http://www. -- Aleksej StrukMaster Degree StudentFree University of Bozen-BolzanoFaculty of Computer Sciencephone: +39-0471-061749cell phone: +39-3204627049 [EMAIL PROTECTED] [EMAIL PROTECTED] - http://www.
[E-devel] module configuration BUG
Hi all, I've found one interesting bug. For example, let say, that first I launch the configuration dialog of a module. Second, I unload that module using enlightenment_remote. Finally, if i click on the apply/ok button in the configuration dialog of the module, then E crashes. Thanks Aleksej-- Aleksej StrukMaster Degree StudentFree University of Bozen-BolzanoFaculty of Computer Sciencephone: +39-0471-061749cell phone: +39-3204627049 [EMAIL PROTECTED] [EMAIL PROTECTED] - http://www.
Re: [E-devel] Design idea for the configuation panel (aka my two cents)
Hey, I have to admit that I'm personally a fan of the current system (many small windows) - it was that way under E16 too, and the control panel is shaping up pretty nicely. All it needs is that the layout could be 3x3 instead of 1x8, but it's not bad right now either though if you ask me. Either way, yup, it's a question of opinion. Does indeed deserve a discussion though. cheers, ValtteriOn 12/29/05, CGA [EMAIL PROTECTED] wrote: Good Day to you all e-devs and thank you for your great job =) As you can understand from the subject of this e-mail I'm here to suggest you a design idea for the configuration panel, take it or leave it, it's up to you. Obviously *anyone* can post impressions and improvements of this idea if they like. Now, i was wandering if you plan to make the configuration panel and all the sub-options one monolithic window... it could be nicer to have something as will follow, rather than to have many windows open like in this screenie: http://www0.get-e.org/Screenshots/User_Submitted/_images/dialogs.png -- Of course it is not compulsory to have all of them open at one time, but this is not the main point. The point is to have *always* one piece and not to have a second (third, fourth and so on..) window opened for the config option one choses to open. To let you understand better i'll use an example: My idea in example: #1- the config panel opens like it does now from the main menu, and opens the configuration panel main window. #2- when you click on a configuration item (let's say background settings) , that slides off on the right of the main window (pretty much like the eclair's cover thing) and presents you the configuration you have chosen. (let's say background settings) in basic mode. #2a- advanced mode might have few lines explaining the user what's all about. #3- if one leaves the background settings before he applied the change , there should be a warning save the changes? and the likes. #4- when one leaves the current config dialogue for another, then the first slides back in and the second slides off afterwards. there might be room for great eye-candy here, like eg: transparency or fade in fade out. #5- if one clicks on the advanced settings the whole pc must implode. #6 -whatever you like, i'm out of ideas. best regards and thank you again for the whole E project =) ps: the txt attached is the log of the #edevelop chat where this started.-- Callea Gaetano Andrea [EMAIL PROTECTED]
[E-devel] color classes
I've always been a fan of color classes for color-agnostic theming, so
I'd like to move them from the background to being fully usable. First a
quick overview (for the lurkers on the list).
A color class is simply a string label attached to an edje state. From
code, an application can specify a given color for that class. All parts
will then be multiplied by this color. Edje provides two methods for
setting the colors, edje_color_class_set() and
edje_object_color_class_set(). The first sets the class in a global
context (for the current process), while the latter sets it only on the
specified object. The object context takes precedence over the global one.
The best way to make a theme color classed is to draw it in grayscale,
so the resultant colored image will be as close to the color chosen as
possible. However, there is no way in edje to specify a default color
for a class. In Winter, I have just been setting the color of the part
itself. However, if the color class is then set to a different color,
the two colors a multiplied together. The cc color can't override the
part color, since the part color is used for fading, etc.
So, I have written a patch that adds a color_classes block to .edc's:
color_classes {
color_class {
name: foo;
color: 229 239 255 255;
color2: 0 0 0 0;
color3: 0 0 0 0;
}
}
(color2 and color3 are for text outlines and shadows)
This block can be placed almost anywhere in the .edc, but is actually
global to the file (much like images are).
Now, when loading up the .edj, I originally had it setting the cc on the
new object (as opposed to the global context). This would prevent on
theme (say the pager module) from changing the color of another (e.g.
the border) if they were loaded from different files. However, the next
step is to create a dialog to set color classes. When one is changed, it
would be quickest to just set the global cc to that, rather than running
through all the objects and setting it at the obj level. BUT, since the
theme specified cc was being set at the obj level it would override this.
So, I'm not sure how best to do it. Either we load the file level cc's
into the global context (and suffer collisions), or we need a new level
of precedence. Something like: edje_file_cc global_cc object_cc.
What do ya'll think?
Also, i would have thought that this patch would break backwards
compatabilty, but old edjes *seem* to work with the patched libedje...
--
rephorm
? cc.diff
Index: src/bin/edje_cc_handlers.c
===
RCS file: /cvsroot/enlightenment/e17/libs/edje/src/bin/edje_cc_handlers.c,v
retrieving revision 1.64
diff -u -r1.64 edje_cc_handlers.c
--- src/bin/edje_cc_handlers.c 13 Dec 2005 15:11:21 - 1.64
+++ src/bin/edje_cc_handlers.c 30 Dec 2005 05:39:12 -
@@ -15,6 +15,12 @@
static void st_styles_style_base(void);
static void st_styles_style_tag(void);
+static void ob_color_class(void);
+static void st_color_class_name(void);
+static void st_color_class_color(void);
+static void st_color_class_color2(void);
+static void st_color_class_color3(void);
+
static void ob_collections(void);
static void ob_collections_group(void);
@@ -105,6 +111,10 @@
{styles.style.name, st_styles_style_name},
{styles.style.base, st_styles_style_base},
{styles.style.tag, st_styles_style_tag},
+ {color_classes.color_class.name, st_color_class_name},
+ {color_classes.color_class.color, st_color_class_color},
+ {color_classes.color_class.color2, st_color_class_color2},
+ {color_classes.color_class.color3, st_color_class_color3},
{collections.image, st_images_image}, /* dup */
{collections.images.image, st_images_image}, /* dup */
{collections.font, st_fonts_font}, /* dup */
@@ -112,6 +122,10 @@
{collections.styles.style.name, st_styles_style_name}, /* dup */
{collections.styles.style.base, st_styles_style_base}, /* dup */
{collections.styles.style.tag, st_styles_style_tag}, /* dup */
+ {collections.color_classes.color_class.name, st_color_class_name}, /*
dup */
+ {collections.color_classes.color_class.color, st_color_class_color}, /*
dup */
+ {collections.color_classes.color_class.color2, st_color_class_color2},
/* dup */
+ {collections.color_classes.color_class.color3, st_color_class_color3},
/* dup */
{collections.group.name, st_collections_group_name},
{collections.group.min, st_collections_group_min},
{collections.group.max, st_collections_group_max},
@@ -123,6 +137,10 @@
{collections.group.styles.style.name, st_styles_style_name}, /* dup */
{collections.group.styles.style.base, st_styles_style_base}, /* dup */
{collections.group.styles.style.tag, st_styles_style_tag}, /* dup */
+ {collections.group.color_classes.color_class.name,
st_color_class_name}, /* dup */
+
