Re: [E-devel] evas build config problem
On 10/8/05, Gabriel Rossetti <[EMAIL PROTECTED]> wrote: > I used Gentoo's ebuilds and not yours, and I also get this same error. Mike (vapier) broke it 4 days ago by adding $(use_enable X software-xcb) to the ebuild [1]. hopefully he fixes it soon (hint hint, nudge nudge, CC :) ) [1] http://www.gentoo.org/cgi-bin/viewcvs.cgi/x11-libs/evas/evas-.ebuild?r1=1.8&r2=1.9 d# > > Gabriel > > On 10/7/05, Mike Russo <[EMAIL PROTECTED]> wrote: > > > evas seems to think I want to build with xcb, but I don't have it > installed: > > checking for shmat... (cached) yes > checking for IceConnectionNumber in -lICE... (cached) yes > checking for xcb-icccm... Package xcb-icccm was not found in the > pkg-config search path. Perhaps you should add the directory containing > `xcb-icccm.pc' to the PKG_CONFIG_PATH environment variable No package > 'xcb-icccm' found > configure: error: Library requirements (xcb-icccm) not met; consider > adjusting the PKG_CONFIG_PATH environment variable if your libraries are > in a nonstandard prefix so pkg-config can find them. > > !!! Please attach the config.log to your bug report: > !!! > /var/tmp/portage/evas-/work/e17/libs/evas/config.log > > Looking at the attached config.log, the ebuild is passing > --enable-software-xcb to aclocal, so it's not an e17 problem per se, but > Mike reads this list... ;) > > -- > Mike Russo > ReadQ Systems, Inc. > (212) 425 3680 x105 > > Random quote of the last-time-I-ran-bash: > Worst Month of 1981 for Downhill Skiing: > August. The lift lines are the shortest, though. > -- Steve Rubenstein --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas build config problem
On Monday 10 October 2005 05:38 am, David Sharp wrote: > On 10/8/05, Gabriel Rossetti <[EMAIL PROTECTED]> wrote: > > I used Gentoo's ebuilds and not yours, and I also get this same error. > > Mike (vapier) broke it 4 days ago by adding $(use_enable X > software-xcb) to the ebuild [1]. hopefully he fixes it soon (hint > hint, nudge nudge, CC :) ) looks like it requires xcb-util which isnt portage yet -mike --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Pager icons stacked incorrectly.
for some reason, xffm's icon in the pager likes to always be on top, even if, eg, firefox is above it on screen. I don't have an eapp for xffm, which makes me think that this can be generalized to apps that provide their own icon. It is only the icon though, not the whole mini-window; the mini-window appears in its propper stacking order. d# --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: E CVS: apps/eclair shadoi
enlightenment-cvs@lists.sourceforge.net wrote: Enlightenment CVS committal Author : shadoi Project : e17 Module : apps/eclair Dir : e17/apps/eclair Modified Files: Makefile.am configure.in Remember to add changelog to .cvsignore and remove it from cvs! Why should both debian/changelog and debian/changelog.in be in EXTRA_DIST? Log Message: - Autogenerate the debian changelog - Added docs to package. === RCS file: /cvsroot/enlightenment/e17/apps/eclair/Makefile.am,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- Makefile.am 17 Apr 2005 08:30:55 - 1.1 +++ Makefile.am 10 Oct 2005 20:09:26 - 1.2 @@ -5,7 +5,7 @@ MAINTAINERCLEANFILES = Makefile.in aclocal.m4 config.guess \ config.h.in config.sub configure install-sh \ ltconfig ltmain.sh missing mkinstalldirs \ - stamp-h.in + stamp-h.in debian/changelog install-data-local: @$(NORMAL_INSTALL) @@ -26,4 +26,7 @@ fi -EXTRA_DIST = README AUTHORS COPYING +EXTRA_DIST = README AUTHORS COPYING TODO NEWS \ + debian/changelog debian/changelog.in \ + debian/rules debian/control debian/copyright \ + debian/eclair.files === RCS file: /cvsroot/enlightenment/e17/apps/eclair/configure.in,v retrieving revision 1.14 retrieving revision 1.15 diff -u -3 -r1.14 -r1.15 --- configure.in13 Jul 2005 22:32:30 - 1.14 +++ configure.in10 Oct 2005 20:09:26 - 1.15 @@ -177,6 +177,7 @@ data/themes/swallow_me/Makefile data/widget_themes/Makefile data/widget_themes/default/Makefile +debian/changelog ],[ ]) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-cvs mailing list enlightenment-cvs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: proto moom16
I'm going to weigh in on this one a little bit. My apologies if I come off a little stronger than the previous objections did -- hopefully everyone can see this matter from a rational viewpoint as I observe it. I really do not get the point of this effort either, even after the explanation. How is it that we have *three* different widget toolkit implementations in CVS, in spite of our shortage of human resources in this project? It is a massive waste of effort and a major step backwards, in my humble opinion. We've been working on this for over three years and we still don't have a decent toolkit to show for it -- and our answer to it is fragmentation? I really appreciate the amount of work you've done Simon, and I respect your contributions to this project. But I think this should be killed. And eblocks too. If there are things in Etk that are implemented better than in EWL, then if necessary kill the corresponding EWL widget and rewrite it the better way. There's nothing in EWL that cannot be fixed, even if it requires major, API-breaking, structure-changing fixes. It's still better than fragmenting efforts and somehow hoping everything will magically work together sometime in the distant future. Having two, nay three, widget toolkits competing in the *same* CVS repository, within the same project, for a limited number of human resources *is* bad. Very bad. I just don't see how this is going to move us forward here. Let's think rationally, get our priorities right and pull our resources together in the right direction. We've done a lot of work here and the rest of the world is beginning to see it and appreciate what we have done. But we can still do much better, and this is not the way. Ibukun > Hi Nathan, Hi Brian, > > First, I have to say that I'm sorry for having kept Etk secret and send it to the CVS without any notification, it was probably the worst way to proceed. > Now, the reasons why I have started Etk: as I always said, I wasn't fully satisfied with ewl because it didn't worked as I expected it to do. So I tried for a (short, I agree) moment to improve it by making a patch for the grid container (which didn't solve all the problems, but the idea of the fix was there), by making a theme (it has never been finished because there were a lot of widget size/placement problem with this theme). I also send a list of 4 bugs/incorrect behaviors for the menu widgets, but they've never been fixed. > > Now, that's true that Etk and Ewl are in direct competition, both dev teams won't give up their job, and the two projects can't blend together since they are really two different. The only solution I see is that the two libs will have to coexist, which is not really bad, it could even become a way to work better/faster (CodeWarrior and I are already helping each other on eblocks/etk). Some projects will be made with etk, and other with ewl. The only thing is that it will be definitively confusing for the user, and will give two different looks to the apps. For the last point, I think it could be fixed if the themes of Etk and Ewl become compatible but it may be hard. > > About the licence, I'm not against the BSD licence, it's just that Etk takes a lot of concepts from GTK (hence the name Etk): properties, signals, resize system and the API. No code has been taken, everything has been recoded, but I'm not sure it won't cause licence problems anyway. So for now, it will stay under LGPL until I'm sure there is no licence problem. > > Regards, > Simon TRENY > > > Brian Mattern a écrit : > >>I'm getting a segv on etk_test here (bt below). I have to agree with Nathan though. I definitely see nothing wrong with implementing your own toolkit. However, we could probably get ALOT more done if we pooled our efforts instead of constantly redoing things. I am curious also, as to what faults EWL has that led you to design and write your own toolkit. >> >>There are definitely two main styles of toolkits in E right now. A traditional, packed toolkit (ewl, etk, eblocks), and an edje + smart object based toolkit (esmart, various smartobjs in apps/e). I definitely see these two styles as coexisting nicely, and worth the somewhat duplicated effort. However, I really fail to see the need for multiple packed toolkits. >> >>Some other little things. Before committing large projects to CVS (even to proto), send a note to the list explaining what the project is. Also, in your initial commit, make the message a little more descriptive. So, instead of "Import of Eczema", say "Import of Eczema, a new application that cures that obnoxious condition everyone's been mistaking for dandruff all these years..." >> >>As for licensing, you're definitely free to build on our code and slap whatever the hell license you want on it (we DO use the anarchist license after all...) BUT, its still a bit rude. And means your library won't get as much usage by E folk. (MEJ'll give you hell... :):) >> >>Anyway, I hope you don't think we're attacki
Re: [E-devel] Pager icons stacked incorrectly.
On Mon, 10 Oct 2005 10:44:18 -0700 David Sharp <[EMAIL PROTECTED]> babbled: > for some reason, xffm's icon in the pager likes to always be on top, > even if, eg, firefox is above it on screen. I don't have an eapp for > xffm, which makes me think that this can be generalized to apps that > provide their own icon. It is only the icon though, not the whole > mini-window; the mini-window appears in its propper stacking order. indeed - well spotted. that's bizarre. should work. must have something up with the stacking code > d# > > > --- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
On Thursday, 06 October 2005, at 03:20:19 (-0500), Nathan Ingersoll wrote: > > 1) EWL just doesn't FEEL right. Meaning: When you open up an EWL > > application (e.g. e_util_eapp_edit), things don't respond the way one > > would expect. Resizing is often buggy, cursors / highlighting in text fields > > is strange, etc. > > There are definitely some issues here but I think they've improved > considerably over the last year. There are examples of some fairly > complex layout being done successfully in the test app now as well > as a filemanager written by chaos. The filedialog in particular is > packed pretty nicely, along with the theme test which shows off some > of the theming features EWL incorporates. Are there minor, mostly-cosmetic issues here and there with EWL? Yes. Are there features missing from some widgets? Yes. Is that a design flaw that requires a rewrite? NO. > I think we can be cut some slack on the text fields as they were > completely reworked this summer and are fairly complex. They do a > reasonable job towards handling multiline text manipulation with > textblock, which is not an easy thing to do, as CodeWarrior should > know. We do need some auto-scrolling code added, but I've written > that code enough times (Epplets, and a few versions of EWL's text > handlers) that I'd rather not do it again. Again, this is simply additional code that must be written, not a design flaw. > 2) It would take longer to learn the EWL internals to be able to > > meaningfully contribute than it would to simply start afresh. That is a crock of shit if I ever heard one. It always takes more time to create something new of equal calibur than it does to learn what's already there. The only way it takes less time to "start afresh" is there are serious design flaws that can only be overcome by a complete bottom-to-top overhaul. And NOT ONE concrete example of a true design flaw has been pointed out yet. Not even one. > The argument being made is that it's easier to design and write > 12985 lines of code and documentation spread across 70 files than it > is to read and understand 11193 lines of code and documentation? Anyone with half a brain should know that that isn't true. This argument is simply an example of grasping at straws in an effort to forward one's own political agenda (in this case, ETK) when one simply cannot come up with *actual* valid reasons. > 3) EWL was designed for Ebits and the original incarnations of Evas and > > Ecore. The many moves to newer > > libraries (Edje, modern Evas/Ecore), although commendable, may have > > introduced a number of bugs. So what? I could also say, "ETK, while commendable, has introduced a number of bugs." And judging by the number of stories I've heard here and on IRC about ETK seg-faulting out the ass, I'd be talking about very real, very concrete bugs that DO EXIST. You're talking about bugs that MAY or MAY NOT exist. > Do we not see the major logic gap here? Did anyone bother to ask how > much the code changed with those ports? Would you be surprised if I > said that each of those ports involved changing about 100 lines of > code? All of these ports improved the code because the basis it was > built on was more solid and gave us a chance to learn where code > duplication crept in and refactor it. > > Currently, EWL has 193 references to Evas functions and 31 > references to Edje calls. If for some reason there was another Evas > rewrite, or a better canvas or Edje-like lib came around that worked > on a somewhat similar model, EWL could be ported fairly easily. In > fact, we could split out these points into theme engine hooks and > drawing methods if we really saw a good need to support more than > Evas and Edje (plus renaming a few internal functions). I appreciate that you are able to respond to the FUD with actual, well-thought-out arguments. I just wish those in the ETK "camp" could do likewise. > You're right about the looks, I've changed the default theme to the > e17 for now to give it a better match to the default window manager > look. I don't know how many times I can say it, but WE NEED HELP > THEMING! I am decent with basic graphics, but given the choice > between working on code and working on the theme, the code always > wins. A lot of the default theme is just hacks I put in place so I > could see the results of the code. The e17 theme is at least better > than that. And the look of the default theme has NOTHING WHATSOEVER to do with code or design, and it certainly does not make an argument for a rewrite. > Good question, and there only one answer I can give you: it's my > fault. The base of EWL has been changing and evolving, making it > very difficult to have a stable API to write higher level widgets on > top of and to debug some of the issues with lower level widgets. It > has stabilized a fair amount over the last year which has allowed us > to work out more of the layout issues. There has been a ton of work >
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
I've been thinking a lot about this whole EWL/ETK mess. Is there ANY way for these two projects to co-exist? Even share some of the same code? Could ETK be merged with EWL (perhaps have separate name spaces for each API under EWL?), at least then, applications can still link to EWL but use either API style. That is what we're talking about mainly here, is the fact that ETK emulates GTK while EWL has a new implementation. I know this would be a lot of work. There's bound to be useless duplication, but at least it could be kept to a minimum, and there wouldn't be this huge fork in the road for new applications (and existing ones) to make a decision which E toolkit they're going to use. Are both sides willing to work together to provide a way out of this mess? If (and I suspect) the answer is no, then I vote for removing ETK and have it be an outside project. Not that a "vote" has been called... -Blake --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Hide the Analog Clock
Hi all,
I've created a patch that allows you to hide the analog clock while
still showing the digital clock. This work is just a small
extension of the patch in this thread:
http://sourceforge.net/mailarchive/message.php?msg_id=12329813
--- default_clock.edc.old 2005-10-10 20:33:31.0 -0500
+++ default_clock.edc 2005-10-10 20:32:32.0 -0500
@@ -195,16 +195,23 @@
new v;
new isAfternoon;
new digiBuf[2];
+ new alogBuf[2];
new digitalStyle;
new DIGITAL_STYLE_NONE, DIGITAL_STYLE_NORMAL, DIGITAL_STYLE_24HOUR;
+ new analogStyle;
+ new ANALOG_STYLE_DISABLED;
DIGITAL_STYLE_NONE = 0;
DIGITAL_STYLE_NORMAL = 1;
DIGITAL_STYLE_24HOUR = 2;
+ ANALOG_STYLE_DISABLED = 1;
+
get_text(PART:"digitalStyle", digiBuf, 2);
+ get_text(PART:"analogStyle", alogBuf, 2);
digitalStyle = atoi(digiBuf);
+ analogStyle = atoi(alogBuf);
date(year, month, day, yearday, weekday, hour, minute, second);
v = round(second);
@@ -281,6 +288,19 @@
set_state(PART:"digital_bg", "hidden", 0.0);
set_state(PART:"digital_bg_overlay", "hidden", 0.0);
}
+
+ if (analogStyle == ANALOG_STYLE_DISABLED) {
+ set_state(PART:"bg", "hidden", 0.0)
+ set_state(PART:"fg", "hidden", 0.0)
+
+ set_state(PART:"seconds", "hidden", 0.0);
+ set_state(PART:"minutes", "hidden", 0.0);
+ set_state(PART:"hour", "hidden", 0.0);
+ }
+ else {
+ set_state(PART:"bg", "default", 0.0)
+ set_state(PART:"fg", "default", 0.0)
+ }
}
}
parts {
@@ -293,6 +313,14 @@
normal: "e17_clock_bg.png";
}
}
+ description {
+ state: "hidden" 0.0;
+ visible: 0;
+ image {
+ normal: "e17_ibox_over_h.png";
+ middle: 0;
+ }
+ }
}
#ifdef IND
# undef IND
@@ -325,6 +353,14 @@
normal: "e17_clock_"IND"_"num".png"; \
} \
}
+ description {
+ state: "hidden" 0.0;
+ visible: 0;
+ image {
+ normal: "e17_ibox_over_h.png";
+ middle: 0;
+ }
+ }
HAND("00")
HAND("01")
HAND("02")
@@ -417,6 +453,14 @@
normal: "e17_clock_"IND"_"num".png"; \
} \
}
+ description {
+ state: "hidden" 0.0;
+ visible: 0;
+ image {
+ normal: "e17_ibox_over_h.png";
+ middle: 0;
+ }
+ }
HAND("00")
HAND("01")
HAND("02")
@@ -509,6 +553,14 @@
normal: "e17_clock_"IND"_"num".png"; \
} \
}
+ description {
+ state: "hidden" 0.0;
+ visible: 0;
+ image {
+ normal: "e17_ibox_over_h.png";
+ middle: 0;
+ }
+ }
HAND("00")
HAND("01")
HAND("02")
@@ -585,6 +637,14 @@
normal: "e17_clock_fg.png";
}
}
+ description {
+ state: "hidden" 0.0;
+ visible: 0;
+ image {
+ normal: "e17_ibox_over_h.png";
+ middle: 0;
+ }
+ }
}
part {
name: "digital_bg_area";
@@ -687,7 +747,7 @@
text {
text: "00:00:00 AM";
font: "Edje-Vera";
- size: 15;
+ size: 16;
fit: 0 1;
align: 0.5 0.5;
}
@@ -705,6 +765,14 @@
visible: 0;
}
}
+ part {
+
name:
"analogStyle";
+ type: TEXT;
+ description {
+ state: "hidden" 0.0;
+ visible: 0;
+ }
+ }
}
programs {
program {
--- cvs/e17/apps/e/src/modules/clock/e_mod_main.h 2005-09-24 08:42:05.0 -0500
+++ e_mod_main.h 2005-10-10 20:31:44.0 -0500
@@ -20,6 +20,9 @@
int
digitalStyle
;
+ int
+ analogStyle
+ ;
};
struct _Clock
@@ -35,6 +38,7 @@
E_Container *con;
E_Menu *menu;
E_Menu *digital_menu;
+ E_Menu *analog_menu;
Config_Face *conf;
struct {
--- cvs/e17/apps/e/src/modules/clock/e_mod_main.c 2005-09-24 08:42:05.0 -0500
+++ e_mod_main.c 2005-10-10 20:31:52.0 -0500
@@ -25,6 +25,8 @@
static void _clock_face_cb_digital_none(void *data, E_Menu *m, E_Menu_Item *mi);
static void _clock_face_cb_digital_normal(void *data, E_Menu *m, E_Menu_Item *mi);
static void _clock_face_cb_digital_24hour(void *data, E_Menu *m, E_Menu_Item *mi);
+static void _clock_face_cb_analog_disabled(void *data, E_Menu *m, E_Menu_Item *mi);
+static void _clock_face_cb_analog_enabled(void *data, E_Menu *m, E_Menu_Item *mi);
static int _clock_count;
@@ -37,6 +39,11 @@
DIGITAL_STYLE_24HOUR = 2
;
+const int
+ ANALOG_STYLE_DISABLED = 0,
+ ANALOG_STYLE_ENABLED = 1
+;
+
/* public module routines. all modules must have these */
E_Module_Api e_modapi =
{
@@ -94,7 +101,7 @@
e_modapi_about(E_Module *mo
[E-devel] imlib2 weirdness on Solaris/sun4u
I have this image: http://goanna.cs.rmit.edu.au/~emil/imlib2/ex.png I have installed imlib2-1.2.1.008 on a SPARC running Solaris: $ uname -srvmp SunOS 5.10 Generic_118822-18 sun4u sparc Using imlib2_view to view the image gives me weird results. Using X over SSH from my FreeBSD/x86 workstation, it looks like this: http://goanna.cs.rmit.edu.au/~emil/imlib2/imlib_freebsd.png Using XDMCP from a NeoWare thin client, it looks like this: http://goanna.cs.rmit.edu.au/~emil/imlib2/imlib_neoware.png (I have no idea where the transparency came from in that image, it was xwd | xwdtopnm | pnmtopng) Running imlib2_view on my workstation displays the image correctly. Running Firefox or Opera on the SPARC displays the image correctly. Any ideas as to what's wrong? Any further diagnostics I can provide? --Emil --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] imlib2 weirdness on Solaris/sun4u
On Tue, 11 Oct 2005 13:36:30 +1000 Emil Mikulic <[EMAIL PROTECTED]> babbled: > I have this image: > http://goanna.cs.rmit.edu.au/~emil/imlib2/ex.png > > I have installed imlib2-1.2.1.008 on a SPARC running Solaris: > $ uname -srvmp > SunOS 5.10 Generic_118822-18 sun4u sparc > > Using imlib2_view to view the image gives me weird results. > Using X over SSH from my FreeBSD/x86 workstation, it looks like this: > http://goanna.cs.rmit.edu.au/~emil/imlib2/imlib_freebsd.png > > Using XDMCP from a NeoWare thin client, it looks like this: > http://goanna.cs.rmit.edu.au/~emil/imlib2/imlib_neoware.png > > (I have no idea where the transparency came from in that image, it was > xwd | xwdtopnm | pnmtopng) > > Running imlib2_view on my workstation displays the image correctly. > Running Firefox or Opera on the SPARC displays the image correctly. > > Any ideas as to what's wrong? Any further diagnostics I can provide? if you load the image into gimp, convert to RGB format and save as another file - does it display properly then? > --Emil > > > --- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] imlib2 weirdness on Solaris/sun4u
On Tue, Oct 11, 2005 at 12:43:15PM +0900, Carsten Haitzler wrote: > On Tue, 11 Oct 2005 13:36:30 +1000 Emil Mikulic <[EMAIL PROTECTED]> > babbled: > > I have this image: http://goanna.cs.rmit.edu.au/~emil/imlib2/ex.png > > if you load the image into gimp, convert to RGB format and save as > another file - does it display properly then? No. =( The converted image: http://goanna.cs.rmit.edu.au/~emil/imlib2/ex_rgb.png Seeing the same problem as before, tested on both displays (workstation and thin client) --Emil --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] imlib2 weirdness on Solaris/sun4u
On Tue, 11 Oct 2005 13:54:14 +1000 Emil Mikulic <[EMAIL PROTECTED]> babbled: > On Tue, Oct 11, 2005 at 12:43:15PM +0900, Carsten Haitzler wrote: > > On Tue, 11 Oct 2005 13:36:30 +1000 Emil Mikulic <[EMAIL PROTECTED]> > > babbled: > > > I have this image: http://goanna.cs.rmit.edu.au/~emil/imlib2/ex.png > > > > if you load the image into gimp, convert to RGB format and save as > > another file - does it display properly then? > > No. =( > > The converted image: > http://goanna.cs.rmit.edu.au/~emil/imlib2/ex_rgb.png > > Seeing the same problem as before, tested on both displays (workstation > and thin client) can you give me a dump of xdpyinfo for those 2 displays? > --Emil > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] imlib2 weirdness on Solaris/sun4u
On Tue, Oct 11, 2005 at 01:02:25PM +0900, Carsten Haitzler wrote: > On Tue, 11 Oct 2005 13:54:14 +1000 Emil Mikulic <[EMAIL PROTECTED]> babbled: > > Seeing the same problem as before, tested on both displays (workstation > > and thin client) > > can you give me a dump of xdpyinfo for those 2 displays? Sure thing. http://goanna.cs.rmit.edu.au/~emil/imlib2/dpyinfo-freebsd.txt http://goanna.cs.rmit.edu.au/~emil/imlib2/dpyinfo-neoware.txt --Emil --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The current state of E Widget ToolKit Libraries (EWTKL)
I say *no*. This ETK serves nothing other than to impede progress, introduce confusion and serve one particular author's specific needs/wants. If you guys really think ETK is the greatest thing since sliced bread, please start another SF project for it. This is not serving the Enlightenment project any good. Over three years of solid work and experience have been put into EWL by hardworking developers, and up to this point nobody has been able to come up with any semblance of a valid reason why it should be replaced by some upstart piece of code rudely thrown into CVS by an excited newcomer. This needs to go away, plain and simple. Any other decision would be utterly immature, anarchistic and ultimately catastrophic for the E project as a whole. I appreciate Nathan's modesty in wanting to permit others to "do their thing", but last I checked, this was the Enlightenment project, not an international code obfuscation competition. You play with the team, or you don't. Ibukun shadoi wrote: I've been thinking a lot about this whole EWL/ETK mess. Is there ANY way for these two projects to co-exist? Even share some of the same code? Could ETK be merged with EWL (perhaps have separate name spaces for each API under EWL?), at least then, applications can still link to EWL but use either API style. That is what we're talking about mainly here, is the fact that ETK emulates GTK while EWL has a new implementation. I know this would be a lot of work. There's bound to be useless duplication, but at least it could be kept to a minimum, and there wouldn't be this huge fork in the road for new applications (and existing ones) to make a decision which E toolkit they're going to use. Are both sides willing to work together to provide a way out of this mess? If (and I suspect) the answer is no, then I vote for removing ETK and have it be an outside project. Not that a "vote" has been called... -Blake --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] imlib2 weirdness on Solaris/sun4u
On Tue, 11 Oct 2005 14:16:27 +1000 Emil Mikulic <[EMAIL PROTECTED]> babbled: > On Tue, Oct 11, 2005 at 01:02:25PM +0900, Carsten Haitzler wrote: > > On Tue, 11 Oct 2005 13:54:14 +1000 Emil Mikulic <[EMAIL PROTECTED]> > > babbled: > > > Seeing the same problem as before, tested on both displays (workstation > > > and thin client) > > > > can you give me a dump of xdpyinfo for those 2 displays? > > Sure thing. > > http://goanna.cs.rmit.edu.au/~emil/imlib2/dpyinfo-freebsd.txt > http://goanna.cs.rmit.edu.au/~emil/imlib2/dpyinfo-neoware.txt you're not going to like this: i don't know. those 2 visuals (16bpp fbsd, and 24bpp neoware) look slike perfectly normal truecolor visuals - standard. the only thing that makes sense here is that maybe imlib2 is not byteswapping. that could be it as the source will be big endian and destination little endian. i guess i should put that code in. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
