Enlightenment

On Sun, 16 Mar 2003 12:56:23 +0100 Kim Woelders <kim@...> babbled:

> Hi there,
> 
> I like Enlightenment (E16). I also like having a dock with tasklist and
> pager. Therefore I didn't upgrade my Gnome(/KDE) stuff to the newer
> versions that are incompatible with Enlightenment, until last week.
> 
> Anyway, I implemented parts of the "Extended Window Manager Hints"
> handling that is required to be compatible with the newer Gnome/KDE
> versions.
> 
> My primary focus has been on making things work (for me) on RH-8.0
> with a Gnome desktop. I have tried not to break backward compatibility
> (although it probably would be cleaner an more efficient just to take
> out the old Gnome/KDE stuff). Things also seem to work fairly OK on a
> RH-8.0 KDE desktop.
> I have not tested with Gnome>2.0 or KDE>3.0.
> 
> Many things work, and some do not. In particular, the "large desktops"
> do not work as they should with the new Gnome/KDE pagers and tasklists
> (they simply have not implemented this feature).
> RH-8.0 comes with gnome-panel-2.0.6. I suggest to upgrade to
> gnome-panel-2.0.11 which "agrees better" with this E16 patch.
> Some things I haven't implemented (e.g. the fullscreen hint), and some
> things don't work as they should (e.g. the maximize hints).
> And then, of course, there are the bugs...
> 
> I'm not sure if/how you want this fairly large patch, so if you are
> interested, grab it here:
> http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16.5-ewmh-kw3.patch.

oh nice. i'm sure people will appreciate this. this may actually be 4enough
reason for a "point release" ie 0.16.6. does anyone agree. personally i dont run
any of the gnome & kde stuff - so can people try the patch and see how it goes?
if it goes ok - lets apply to cvs and maybe roll out a release?

> Kim
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

On Monday, 17 March 2003, at 10:53:29 (+1100),
Carsten Haitzler wrote:

> oh nice. i'm sure people will appreciate this. this may actually be
> 4enough reason for a "point release" ie 0.16.6. does anyone
> agree. personally i dont run any of the gnome & kde stuff - so can
> people try the patch and see how it goes?  if it goes ok - lets
> apply to cvs and maybe roll out a release?

My thoughts exactly. :)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I ask people why they have deer heads on their walls.  They always
  say because it's such a beautiful animal.  There you go.  I think
  my mother is attractive, but I have photographs of her."
                                                    -- Ellen DeGeneres

On Sun, 16 Mar 2003 12:56:23 +0100, Kim Woelders <kim@...>  said:

> My primary focus has been on making things work (for me) on RH-8.0
> with a Gnome desktop. I have tried not to break backward compatibility
> (although it probably would be cleaner an more efficient just to take
> out the old Gnome/KDE stuff). Things also seem to work fairly OK on a
> RH-8.0 KDE desktop.
> I have not tested with Gnome>2.0 or KDE>3.0.

While we're on the topic, has anybody whomped on the e_gen_gnome_menu
script to deal with the Gnome 2.0+ 'desktop' files? (Probably the KDE ones
need whomping too, but I don't have any KDE-ish apps, and I *do* use some
of the Gnome apps under E)...

On Mon, 2003-03-17 at 01:46, Valdis.Kletnieks@... wrote:
> On Sun, 16 Mar 2003 12:56:23 +0100, Kim Woelders <kim@...>  said:
> 
> > My primary focus has been on making things work (for me) on RH-8.0
> > with a Gnome desktop. I have tried not to break backward compatibility
> > (although it probably would be cleaner an more efficient just to take
> > out the old Gnome/KDE stuff). Things also seem to work fairly OK on a
> > RH-8.0 KDE desktop.
> > I have not tested with Gnome>2.0 or KDE>3.0.
> 
> While we're on the topic, has anybody whomped on the e_gen_gnome_menu
> script to deal with the Gnome 2.0+ 'desktop' files? (Probably the KDE ones
> need whomping too, but I don't have any KDE-ish apps, and I *do* use some
> of the Gnome apps under E)...

I seem to remember a few scripts, all I can find right now is:
http://www.geocrawler.com/archives/3/6973/2002/9/0/9665542/

gnome 2 and KDE 3 share menus somewhat.

-- 
BAM - "If something is so complicated that you can't explain it in 10
seconds, then it's probably not worth knowing anyway."
	-- Calvin

On Mon 17 Mar 2003, BAM wrote:
> On Mon, 2003-03-17 at 01:46, Valdis.Kletnieks@... wrote:
> > On Sun, 16 Mar 2003 12:56:23 +0100, Kim Woelders <kim@...>  said:
> > 
> > > My primary focus has been on making things work (for me) on RH-8.0
> > > with a Gnome desktop. I have tried not to break backward compatibility
> > > (although it probably would be cleaner an more efficient just to take
> > > out the old Gnome/KDE stuff). Things also seem to work fairly OK on a
> > > RH-8.0 KDE desktop.
> > > I have not tested with Gnome>2.0 or KDE>3.0.
> > 
> > While we're on the topic, has anybody whomped on the e_gen_gnome_menu
> > script to deal with the Gnome 2.0+ 'desktop' files? (Probably the KDE ones
> > need whomping too, but I don't have any KDE-ish apps, and I *do* use some
> > of the Gnome apps under E)...
 
I believed I hacked them once specifically to work for a mandrake 9.0
system ... it wasn't very general work since Mandrake has its own peculiar
menu system for KDE in /usr/share/applnk-mdk or so. But it might be
useful, so I might try to find the lab machine I did that on and dig out
that script.

-- 
                               |  /*\
Ibukun Olumuyiwa               |  \ /  Join the ASCII Ribbon Campaign
http://xcomputerman.com        |   X   against HTML mail today!
                               |  / \

On Sun, 2003-03-16 at 18:53, Carsten Haitzler wrote:
> if it goes ok - lets apply to cvs and maybe roll out a release?

e16 cvs doesn't work with autoconf 2.5x (autoheader fails). This patch
is just enough to make it compile. 

Could someone test this with an old autoconf and see if it breaks? More
distros have switched to the latest autoconf since this was last
discussed, so a lot of people will need something like this.

-- 
BAM - "The only skills I have the patience to learn are those that have
no real application in life."
	-- Calvin

BAM wrote:
> On Sun, 2003-03-16 at 18:53, Carsten Haitzler wrote:
[snip]

> Could someone test this with an old autoconf and see if it breaks? More
> distros have switched to the latest autoconf since this was last
> discussed, so a lot of people will need something like this.
[snip
Also,  Could someone include the patch so e.16 builds with freetype 2 
(as it installs on RH 7.*)?

Thanks for persuing this.

-- 
Robert G. Werner
rwerner@...
2001/9/11

Lee's Law:
	Mother said there would be days like this,
	but she never said that there'd be so many!

On Mon, 17 Mar 2003 14:40:54 -0800 "Robert G. Werner" <rwerner@...>
babbled:

> BAM wrote:
> > On Sun, 2003-03-16 at 18:53, Carsten Haitzler wrote:
> [snip]
> 
> > Could someone test this with an old autoconf and see if it breaks? More
> > distros have switched to the latest autoconf since this was last
> > discussed, so a lot of people will need something like this.
> [snip
> Also,  Could someone include the patch so e.16 builds with freetype 2 
> (as it installs on RH 7.*)?

there is such a patch? :) its in cvs i believe to build.. but it builds against
freetype1 still.

> Thanks for persuing this.
> 
> -- 
> Robert G. Werner
> rwerner@...
> 2001/9/11
> 
> Lee's Law:
> 	Mother said there would be days like this,
> 	but she never said that there'd be so many!
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

Carsten Haitzler (The Rasterman) wrote:
> On Mon, 17 Mar 2003 14:40:54 -0800 "Robert G. Werner" <rwerner@...>
> babbled:
[snip]
>>Also,  Could someone include the patch so e.16 builds with freetype 2 
>>(as it installs on RH 7.*)?
> 
> 
> there is such a patch? :) its in cvs i believe to build.. but it builds against
> freetype1 still.
[snip]
Actually,  I think it still builds against freetype 1,  as you 
indicated but it is able to handle the include files the way RH lays 
them out (is it RH that does this or the FT2 lib?).  E.16.5 can't find 
the right include file but there is an SRPM out that can.  This is 
probably what you are refering to in CVS.

Also,  another can of worms entirely,  but has anyone ever had any 
luck tracking down the remember bug with eeplets?

-- 
Robert G. Werner
rwerner@...
2001/9/11

Lee's Law:
	Mother said there would be days like this,
	but she never said that there'd be so many!

On Monday, 17 March 2003, at 15:26:53 (-0800),
Robert G. Werner wrote:

> Actually, I think it still builds against freetype 1, as you
> indicated but it is able to handle the include files the way RH lays
> them out (is it RH that does this or the FT2 lib?).  E.16.5 can't
> find the right include file but there is an SRPM out that can.  This
> is probably what you are refering to in CVS.

RPM's/SRPM's for E-related goop are best downloaded from:

http://vermillion.nplus1.net/7.3.1/

> Also, another can of worms entirely, but has anyone ever had any
> luck tracking down the remember bug with eeplets?

AFAIK, there isn't one.  It's more a question of whether or not they
were built properly, and who's doing the session managing.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I always wait until a jury has spoken before I anticipate what they
  will do."                          -- US Attorney General Janet Reno

On Mon, 17 Mar 2003 15:26:53 -0800 "Robert G. Werner" <rwerner@...>
babbled:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 17 Mar 2003 14:40:54 -0800 "Robert G. Werner"
> > <rwerner@...> babbled:
> [snip]
> >>Also,  Could someone include the patch so e.16 builds with freetype 2 
> >>(as it installs on RH 7.*)?
> > 
> > 
> > there is such a patch? :) its in cvs i believe to build.. but it builds
> > against freetype1 still.
> [snip]
> Actually,  I think it still builds against freetype 1,  as you 
> indicated but it is able to handle the include files the way RH lays 
> them out (is it RH that does this or the FT2 lib?).  E.16.5 can't find 
> the right include file but there is an SRPM out that can.  This is 
> probably what you are refering to in CVS.
> 
> Also,  another can of worms entirely,  but has anyone ever had any 
> luck tracking down the remember bug with eeplets?

aaah i can tell you what i think it is... race condition - app exits and does a
"please unremember me" but then the app window goes away and by the time e gets
the "dont remember me " message the window is gone so it doesnt know what to not
remember anymore... we'd need to add a "unremember ok" and have the epplet wait
for that and then exit.


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

Hi there,

Here is a new version of the Extended Window Manager Hints patch:
http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw6.patch
This is a patch on the current CVS version.

It applies nicely to the 0.16.5 source tarball. If you patch the
tarball, you should probably also apply
http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16.5-ewmh-Makefile.in.patch
and run configure.

Changes:

- Proper handling of _NET_WM_WINDOW_TYPE_DESKTOP windows like the
   nautilus desktop (thanks to BAM<solnul@...>).

- Have taken out (using ifdef's) the old Gnome/KDE stuff. I think it
   was begging for trouble to try to handle 3 (+ICCCM +E internals)
   sets of possibly conflicting hints.
   I don't think there is any reason to be backwards compatible (if you
   run old Gnome/KDE desktops, 0.16.5 is just fine).

The patch also includes BAM<solnul@... fix to configure.in to get
auto* going.

/Kim

On Wednesday, 19 March 2003, at 17:52:00 (+0100),
Kim Woelders wrote:

> Here is a new version of the Extended Window Manager Hints patch:
> http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw6.patch
> This is a patch on the current CVS version.
> 
> It applies nicely to the 0.16.5 source tarball. If you patch the
> tarball, you should probably also apply
> http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16.5-ewmh-Makefile.in.patch
> and run configure.

Is there a problem with the 0.16.5 tarball?  If so, I'd like to get
that corrected.  If it's related to newer auto* tools, though, I won't
bother.

> - Have taken out (using ifdef's) the old Gnome/KDE stuff. I think it
>   was begging for trouble to try to handle 3 (+ICCCM +E internals)
>   sets of possibly conflicting hints.
>   I don't think there is any reason to be backwards compatible (if you
>   run old Gnome/KDE desktops, 0.16.5 is just fine).

Are they actually known to conflict?  I'd like to keep them in there
if possible, because 0.16.x will still be the E of choice for most
people for at least another 6 months to a year, I'd say.  Wouldn't you
agree, raster?  And I believe backward compatibility would be useful
to those running things like RHAS or Debian stable.

> The patch also includes BAM<solnul@... fix to configure.in to
> get auto* going.

Just for the record, any patch which breaks compatibility with
autoconf 2.13, automake 1.4, etc. will not be applied to CVS.  So if I
have to strip out that portion, I will.

Again, it looks like raster and I are in agreement that this patch,
along with changes currently in CVS, are worth another "point patch"
release of E.  So all end-user testing results, good and bad, are
appreciated.

Also, just as an FYI, I'm looking at an epplets release in the near
future too; 0.5 is way too antiquated.  And besides, it lacks the most
important epplet of all:  E-Pants.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Three six nine, the goose drank wine; the monkey chewed tobacco on
  the street car line.  The line broke, the monkey got choked, and
  they all went to heaven in a little row boat."      -- Nursery Rhyme

* Michael Jennings (e-devel@...) [030319 18:15]:
> On Wednesday, 19 March 2003, at 17:52:00 (+0100),
> Kim Woelders wrote:
> 
> Is there a problem with the 0.16.5 tarball?  If so, I'd like to get
> that corrected.  If it's related to newer auto* tools, though, I won't
> bother.
> 
> > The patch also includes BAM<solnul@... fix to configure.in to
> > get auto* going.
> 
> Just for the record, any patch which breaks compatibility with
> autoconf 2.13, automake 1.4, etc. will not be applied to CVS.  So if I
> have to strip out that portion, I will.

I know this has come up before, but I just checked my Debian unstable
packages and it's not too bad for me. I've got automake 1.4, but
autoconf is at 2.57. 'dpkg --status autoconf' does tell me this:

    This version of autoconf contains many changes from the previous
    release, version 2.13. If you need support for Autoconf 2.13, you
    must install the autoconf2.13 package as well.

Not sure what people with other distros can do though...

Hall

On Wed, 19 Mar 2003 17:47:14 -0500 Michael Jennings <e-devel@...> babbled:

> On Wednesday, 19 March 2003, at 17:52:00 (+0100),
> Kim Woelders wrote:
> 
> > Here is a new version of the Extended Window Manager Hints patch:
> > http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw6.patch
> > This is a patch on the current CVS version.
> > 
> > It applies nicely to the 0.16.5 source tarball. If you patch the
> > tarball, you should probably also apply
> > http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16.5-ewmh-Makefile.in.patch
> > and run configure.
> 
> Is there a problem with the 0.16.5 tarball?  If so, I'd like to get
> that corrected.  If it's related to newer auto* tools, though, I won't
> bother.
> 
> > - Have taken out (using ifdef's) the old Gnome/KDE stuff. I think it
> >   was begging for trouble to try to handle 3 (+ICCCM +E internals)
> >   sets of possibly conflicting hints.
> >   I don't think there is any reason to be backwards compatible (if you
> >   run old Gnome/KDE desktops, 0.16.5 is just fine).
> 
> Are they actually known to conflict?  I'd like to keep them in there
> if possible, because 0.16.x will still be the E of choice for most
> people for at least another 6 months to a year, I'd say.  Wouldn't you
> agree, raster?  And I believe backward compatibility would be useful
> to those running things like RHAS or Debian stable.

yup. 0.16.x will be around for a while yet :)

> > The patch also includes BAM<solnul@... fix to configure.in to
> > get auto* going.
> 
> Just for the record, any patch which breaks compatibility with
> autoconf 2.13, automake 1.4, etc. will not be applied to CVS.  So if I
> have to strip out that portion, I will.
> 
> Again, it looks like raster and I are in agreement that this patch,
> along with changes currently in CVS, are worth another "point patch"
> release of E.  So all end-user testing results, good and bad, are
> appreciated.

yup.. so how does this patch look/work? things working fine? nothing broken?

> Also, just as an FYI, I'm looking at an epplets release in the near
> future too; 0.5 is way too antiquated.  And besides, it lacks the most
> important epplet of all:  E-Pants.
> 
> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
> n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
>  "Three six nine, the goose drank wine; the monkey chewed tobacco on
>   the street car line.  The line broke, the monkey got choked, and
>   they all went to heaven in a little row boat."      -- Nursery Rhyme
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink? 
> You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
> What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

On Wed, 2003-03-19 at 11:52, Kim Woelders wrote:
> The patch also includes BAM<solnul@... fix to configure.in to get
> auto* going.

Just for the record, I've tried this with automake 1.4/autoconf 2.13 and
it looks OK. If somebody with a distro that actually uses these could
test it, that would be great, though.


-- 
BAM - "There are no lazy veteran lion hunters."
	-- Norman Augustine

On Wednesday, 19 March 2003, at 23:38:58 (-0500),
BAM wrote:

> Just for the record, I've tried this with automake 1.4/autoconf 2.13
> and it looks OK. If somebody with a distro that actually uses these
> could test it, that would be great, though.

It appears to be fine.  The current problems I'm having are due to
gettext. :}

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I had rather men should ask why my statue is not set up, than why it
  is."        -- Cato the Elder (from Plutarch's "Political Precepts")

Carsten Haitzler (The Rasterman) wrote:

> On Wed, 19 Mar 2003 17:47:14 -0500 Michael Jennings  babbled:
>
>
> >On Wednesday, 19 March 2003, at 17:52:00 (+0100),
> >Kim Woelders wrote:
> >
> >
> >>Here is a new version of the Extended Window Manager Hints patch:
> >>http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw6.patch
> >>This is a patch on the current CVS version.
> >>
> >>It applies nicely to the 0.16.5 source tarball. If you patch the
> >>tarball, you should probably also apply
> >>http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16.5-ewmh-Makefile.in.patch
> >>and run configure.
> >
> >Is there a problem with the 0.16.5 tarball?  If so, I'd like to get
> >that corrected.  If it's related to newer auto* tools, though, I won't
> >bother.
> >

Sorry, my mistake. Auto* and I don't agree wery well.
There is no reason for the Makefile.in patch. Just run automake and 
configure.

>
> >
> >>- Have taken out (using ifdef's) the old Gnome/KDE stuff. I think it
> >>  was begging for trouble to try to handle 3 (+ICCCM +E internals)
> >>  sets of possibly conflicting hints.
> >>  I don't think there is any reason to be backwards compatible (if you
> >>  run old Gnome/KDE desktops, 0.16.5 is just fine).
> >
> >Are they actually known to conflict?  I'd like to keep them in there
> >if possible, because 0.16.x will still be the E of choice for most
> >people for at least another 6 months to a year, I'd say.  Wouldn't you
> >agree, raster?  And I believe backward compatibility would be useful
> >to those running things like RHAS or Debian stable.

First, I cannot say that I know that they *do* conflict in some 
particular situation, but looking at the code, I think it is obvious 
that they *may*. In particular I think it is dangerous that the KDE and 
the Gnome hints don't always get set at the same points in the code.
Rather than to try to sort this out I wanted to get the EWMH thing 
right. Also, I had some weirdness, and I wanted to at least be able to 
rule out conflicts with Gnome/KDE hints as the reason.
Everything may work just fine if you don't do a lot of switching between 
window managers (test versions of E16, metacity, kwin, twm, ...), 
between Gnome and KDE, different dock versions, etc. as I have done.

Second, I did intend to add the Gnome/KDE/EWMH support settings 
(currently #define ENABLE_GNOME/KDE/EWMH in E.h) into configure.in.
But... auto* and I...
Some wizard out there could probably do it in 10 minutes :-)

/Kim

On the subject of features/fixes going in to e16, don't suppose anyone
has thought about moving e16 to imlib2?  I know it's in the TODO for
e16... any thoughts?  I'd be interested in helping out with this.
    -James

Carsten Haitzler (raster@...) wrote:
> On Mon, 17 Mar 2003 15:26:53 -0800 "Robert G. Werner" <rwerner@...>
> babbled:
> 
> > Carsten Haitzler (The Rasterman) wrote:
> > > On Mon, 17 Mar 2003 14:40:54 -0800 "Robert G. Werner"
> > > <rwerner@...> babbled:
> > [snip]
> > >>Also,  Could someone include the patch so e.16 builds with freetype 2 
> > >>(as it installs on RH 7.*)?
> > > 
> > > 
> > > there is such a patch? :) its in cvs i believe to build.. but it builds
> > > against freetype1 still.
> > [snip]
> > Actually,  I think it still builds against freetype 1,  as you 
> > indicated but it is able to handle the include files the way RH lays 
> > them out (is it RH that does this or the FT2 lib?).  E.16.5 can't find 
> > the right include file but there is an SRPM out that can.  This is 
> > probably what you are refering to in CVS.
> > 
> > Also,  another can of worms entirely,  but has anyone ever had any 
> > luck tracking down the remember bug with eeplets?
> 
> aaah i can tell you what i think it is... race condition - app exits and does a
> "please unremember me" but then the app window goes away and by the time e gets
> the "dont remember me " message the window is gone so it doesnt know what to not
> remember anymore... we'd need to add a "unremember ok" and have the epplet wait
> for that and then exit.
> 
> 
> -- 
> --------------- Codito, ergo sum - "I code, therefore I am" --------------------
> The Rasterman (Carsten Haitzler)    raster@...
>                                     raster@...
> Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

At 10:57 AM 3/21/2003 -0500, James Moss wrote:

>Carsten Haitzler (raster@...) wrote:
> > On Mon, 17 Mar 2003 15:26:53 -0800 "Robert G. Werner" 
> <rwerner@...>
> > babbled:
> >
> > > Carsten Haitzler (The Rasterman) wrote:
> > > > On Mon, 17 Mar 2003 14:40:54 -0800 "Robert G. Werner"
> > > > <rwerner@...> babbled:
> > > [snip]
> > > >>Also,  Could someone include the patch so e.16 builds with freetype 2
> > > >>(as it installs on RH 7.*)?
> > > >
> > > >
> > > > there is such a patch? :) its in cvs i believe to build.. but it builds
> > > > against freetype1 still.
> > > [snip]
> > > Actually,  I think it still builds against freetype 1,  as you
> > > indicated but it is able to handle the include files the way RH lays
> > > them out (is it RH that does this or the FT2 lib?).  E.16.5 can't find
> > > the right include file but there is an SRPM out that can.  This is
> > > probably what you are refering to in CVS.
> > >
> > > Also,  another can of worms entirely,  but has anyone ever had any
> > > luck tracking down the remember bug with eeplets?
> >
> > aaah i can tell you what i think it is... race condition - app exits 
> and does a
> > "please unremember me" but then the app window goes away and by the 
> time e gets
> > the "dont remember me " message the window is gone so it doesnt know 
> what to not
> > remember anymore... we'd need to add a "unremember ok" and have the 
> epplet wait
> > for that and then exit.

> > On the subject of features/fixes going in to e16, don't suppose anyone
>has thought about moving e16 to imlib2?  I know it's in the TODO for
>e16... any thoughts?  I'd be interested in helping out with this.

I'll bet that none of the primary developers are interested in doing this 
as they're busy with e17. Even if you volunteer and do a good job, they may 
not want to update the "old" version now.

I'm curious what Rasterman or Jennings' response will be...

Hall

Are any major Linux distro's including imlib2 as part of their
distributions?  I rather like being able to build e16  without
having to build a lot of the infrastructure as well.
-Bob Arendt

James Moss wrote:
> On the subject of features/fixes going in to e16, don't suppose anyone
> has thought about moving e16 to imlib2?  I know it's in the TODO for
> e16... any thoughts?  I'd be interested in helping out with this.
>     -James
>

At 10:14 AM 3/21/2003 -0700, Bob Arendt wrote:
>James Moss wrote:
>>On the subject of features/fixes going in to e16, don't suppose anyone
>>has thought about moving e16 to imlib2?  I know it's in the TODO for
>>e16... any thoughts?  I'd be interested in helping out with this.
>>     -James
>>Are any major Linux distro's including imlib2 as part of their
>>distributions?  I rather like being able to build e16  without
>>having to build a lot of the infrastructure as well.
>>-Bob Arendt

Didn't the gnome group do something like "fork" imlib1 or imlib2 to suit 
their needs ?? If so, users may have the "wrong" version of imlib in their 
distros.

Hall

> Are any major Linux distro's including imlib2 as part of their
> distributions? 

Mandrake 9.0 (so I would presume the new 9.1), Gentoo, Debian (unstable),
Yellow Dog.  Red Hat 8.0 does not have it.
Since both Mandrake and Debian have it, that seems to cover the two major
package formats...

Mike

I was under the impression that this move would actually minimise the
infrastructure since imlib2 would take over the role of fnlib as well.
And you don't need the edb or xcf loaders, so really, just build imlib2
and e16.
    -James


Bob Arendt (rda@...) wrote:
> Are any major Linux distro's including imlib2 as part of their
> distributions?  I rather like being able to build e16  without
> having to build a lot of the infrastructure as well.
> -Bob Arendt
> 
> James Moss wrote:
> >On the subject of features/fixes going in to e16, don't suppose anyone
> >has thought about moving e16 to imlib2?  I know it's in the TODO for
> >e16... any thoughts?  I'd be interested in helping out with this.
> >    -James
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

This would actually reduce infrastructure, or at least I'm under the
(mis)belief that it does.  Imlib2 would take over the role of not only
imlib1 but fnlib as well.  You don't need edb or xcf loaders for e16, so
you don't need to build edb itself or the extra loaders.  So, unless I'm
missing something, it would be a reduction.
    -James

P.S. To whomever watches over what emails come from wrong addresses to
the list, delete my previous response from moss@....  Sorry, I
sent from the wrong addr.

Bob Arendt (rda@...) wrote:
> Are any major Linux distro's including imlib2 as part of their
> distributions?  I rather like being able to build e16  without
> having to build a lot of the infrastructure as well.
> -Bob Arendt
> 
> James Moss wrote:
> >On the subject of features/fixes going in to e16, don't suppose anyone
> >has thought about moving e16 to imlib2?  I know it's in the TODO for
> >e16... any thoughts?  I'd be interested in helping out with this.
> >    -James
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Bob Arendt wrote:
> James Moss wrote:
>> On the subject of features/fixes going in to e16, don't suppose anyone
>> has thought about moving e16 to imlib2?  I know it's in the TODO for
>> e16... any thoughts?  I'd be interested in helping out with this.
>>     -James
>> 
> 
> Are any major Linux distro's including imlib2 as part of their
> distributions?  I rather like being able to build e16  without
> having to build a lot of the infrastructure as well.
> -Bob Arendt
>

I should think so, as for one thing, Eterm requires imlib2 these days...

On Friday, 21 March 2003, at 11:19:54 (-0500),
Hall Stevenson wrote:

> I'll bet that none of the primary developers are interested in doing
> this as they're busy with e17. Even if you volunteer and do a good
> job, they may not want to update the "old" version now.
> 
> I'm curious what Rasterman or Jennings' response will be...

I have no plans to write such a patch myself, but were someone else to
do it, and if it worked, I see no reason why it couldn't go into CVS.
As I said to Kim the other day, 0.16.x will be the end-user choice for
some time to come.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 Many things in life are highly overrated.  Chief among them is love.
 No matter what anyone else tells you, nice guys do finish last.
                                          -- Rules of Life #96 and #97

I'm going to spend some time this weekend integrating and testing this
patch on a bunch of machines, and I am currently intending on packaging
up and releasing an 0.16.6 in the not-so-distant future (I do use 0.16
as my desktop still).  I don't think I will spend any time personally
working on an imlib2 patch, but if somebody ELSE wants to take the time
to work on it, I'm more than welcome to listen and incorporate changes.

(sorry for using outlook at work I do win32 development now)

--
Mandrake      (http://mandrake.net)
Cepstral, LLC (http://www.cepstral.com)

> -----Original Message-----
> From: enlightenment-devel-admin@... 
> [mailto:enlightenment-devel-admin@...] On 
> Behalf Of Michael Jennings
> Sent: Friday, March 21, 2003 2:15 PM
> To: e
> Subject: Re: [E-devel] While we await E17...
> 
> 
> On Friday, 21 March 2003, at 11:19:54 (-0500),
> Hall Stevenson wrote:
> 
> > I'll bet that none of the primary developers are interested in doing
> > this as they're busy with e17. Even if you volunteer and do a good
> > job, they may not want to update the "old" version now.
> > 
> > I'm curious what Rasterman or Jennings' response will be...
> 
> I have no plans to write such a patch myself, but were someone else to
> do it, and if it worked, I see no reason why it couldn't go into CVS.
> As I said to Kim the other day, 0.16.x will be the end-user choice for
> some time to come.
> 
> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  
> <mej@...>
> n + 1, Inc., http://www.nplus1.net/       Author, Eterm 
(www.eterm.org)
-----------------------------------------------------------------------
 Many things in life are highly overrated.  Chief among them is love.
 No matter what anyone else tells you, nice guys do finish last.
                                          -- Rules of Life #96 and #97


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@...
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Hi there,

Yet another version of the Extended Window Manager Hints patch:
http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw7.patch
This is a patch on the current CVS version. It applies nicely to the 
0.16.5 source tarball.

Changes since -kw6:

- The epplets use GNOME hints to set layer, stickyness, etc., so
   these are now enabled by default again.

- Skip focuslist for desktop and dock windows.

- I think I got auto* going (--enable-hints-ewmh/gnome/kde).
   Not pretty but it seems to work.

/Kim

Hi again,

Yet another version of the Extended Window Manager Hints patch:
http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw8.patch
This is a patch on the current CVS version. It applies nicely to the 
0.16.5 source tarball.

Changes since -kw7:

- Collect GNOME hint processing in gnome.c.
   Strictly cosmetic.

I'll try to keep quiet a while now :-)

/Kim

Kim Woelders wrote:
> Hi again,
[snip]

> I'll try to keep quiet a while now :-)
> 
> /Kim
[snip]

Please don't.  I'm really excited to see a maintenance release coming 
out for e.16.  If you find something else,  please make lots of noise ;-)

-- 
Robert G. Werner
rwerner@...
2001/9/11

Lots of people drink from the wrong bottle sometimes.
		-- Edith Keeler, "The City on the Edge of Forever",
		   stardate unknown

BAM wrote:
> On Fri, 2003-03-21 at 15:57, Kim Woelders wrote:
> 
>>Yet another version of the Extended Window Manager Hints patch:
>>http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw7.patch
>>This is a patch on the current CVS version. It applies nicely to the 
>>0.16.5 source tarball.
>>
>>Changes since -kw6:
> 
> 
>>- Skip focuslist for desktop and dock windows.
> 
> 
> Sorry if you already considered this, but think about it if you didn't.
I just got annoyed with the dock in the focuslist, and without too much 
thought, the desktop got the same treatment (I don't use the desktop 
window).
> 
> I think this makes a good default for me, but I don't know if it is for
> everyone. I considered including this in my patches to you, but I think
> I mentioned why I didn't.
> 
> I don't know about KDE, but the GNOME panel/desktop were meant to be
> keyboard focusable. They made these windows work the the keyboard, so
> someone could focus the panel and use the applets all without the mouse.
> 
I think the "no mouse" thing is important. I guess the bottom line is 
that somebody should choose a suitable default and that it should be 
possible to override that.

/Kim

On Fri, 21 Mar 2003 10:14:28 -0700 Bob Arendt <rda@...> babbled:

> Are any major Linux distro's including imlib2 as part of their
> distributions?  I rather like being able to build e16  without
> having to build a lot of the infrastructure as well.
> -Bob Arendt

this (in theory) is a good idea. imlib2 could replace imlib-1.x.x but to be
honest i'm not keen to spend time on it myself really. it couldn't replace fnlib
though as fnlib provides full colour pixmap fonts - but no one ever uses this
feature in e0.16.x, but imlib2 could centralize the truetype support in 0.16.x
into that library... but as i said.. i'm not keen to, nor do i have the copuous
extra time to work on this :( (things like a port to use ecore to centralize the
loop management in 0.16 would clean up the code a lot and bring speedups.
theres' lots that could be done, but at which point is the work useful and
should the work instead be focused on 0.17) :)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

* Carsten Haitzler (raster@...) [030322 03:34]:
> On Fri, 21 Mar 2003 10:14:28 -0700 Bob Arendt <rda@...> babbled:
> 
> > Are any major Linux distro's including imlib2 as part of their
> > distributions?  I rather like being able to build e16  without
> > having to build a lot of the infrastructure as well.
> > -Bob Arendt
>
<snip>
> but at which point is the work useful and should the work instead be
> focused on 0.17) :)

I vote for focusing your efforts on e17.

Hall

On Friday, 21 March 2003, at 23:36:11 (+0100),
Kim Woelders wrote:

> Yet another version of the Extended Window Manager Hints patch:
> http://www.woelders.dk/~kw/stuff/e16/enlightenment-0.16-cvs-ewmh-kw8.patch
> This is a patch on the current CVS version. It applies nicely to the 
> 0.16.5 source tarball.
> 
> Changes since -kw7:
> 
> - Collect GNOME hint processing in gnome.c.
>   Strictly cosmetic.
> 
> I'll try to keep quiet a while now :-)

I tested this patch out, and it seems to be working fine.  No problems
yet.  So it's now in CVS; hopefully this will help more people put it
through its paces. :)

Thanks for the patch!

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "That's who I am.  I'm a positive person."  "No, *I'm* a positive
  person.  You are like Santa Claus on Prozac...at Disneyland...
  getting laid!"            -- Alec Baldwin and Lisa Kudrow, "Friends"

Hi there,

Please find attached various minor patches for E16, more
or less related to the Extended Window Manager Hints:

e16-fix-initial-desktop.patch initialises the desktop for
a new window to the current desktop. This avoids that
DetermineEwinArea() called from AddToFamily() accesses
desks.desk[ewin->desktop] with ewin->desktop = -1.

e16-fix-desktop-hint.patch makes sure the current desktop
hint always gets set when calling ConformEwinToDesktop().
Fixes an EWMH problem when sticking/unsticking.

e16-fix-stick-by-wm-desktop.patch implements sick/unstick
by client messages using _NET_WM_DESKTOP in stead of
_NET_WM_STATE.

e16-fix-off-vp-stick.patch puts windows being made sticky
on the current viewport, if not already there. Otherwise
they may seem to get lost.
Fixes problems with taskbars not only showing windows in
the current viewport.

/Kim

Hi again,

Here is yet another set of small patches for E16:

e16-ewmh-handle-vp-change.patch implements handling of
_NET_DESKTOP_VIEWPORT client messages.

e16-move-iconfied-window.patch moves (unsticky) iconfied
windows when the viewport is moved on a desktop (just
like non-iconfied unsticky windows are).
This enables external tasklist handlers to determine
whether or not a window would appear on the current
viewport if un-iconified, i.e., if it should appear in
the list or not.

e16-ewmh-remove-btbhack.patch takes out some disabled
test stuff that shouldn't have gone in in the first place.

I am having a lot of noise and trouble with the auto*
stuff again. "gettextize -f" (output attached) removes
and modifies things that are in CVS (e.g. intl/ and
ABOUT-NLS). configure terminates with:
config.status: creating intl/Makefile
config.status: error: cannot find input file: intl/Makefile.in
(Obviously - gettextize -f just wiped out intl/)


And thanks for accepting my stuff so far :-)

/Kim

On Sunday, 30 March 2003, at 23:03:06 (+0200),
Kim Woelders wrote:

> Here is yet another set of small patches for E16:

Should be in CVS now.

> I am having a lot of noise and trouble with the auto*
> stuff again. "gettextize -f" (output attached) removes
> and modifies things that are in CVS (e.g. intl/ and
> ABOUT-NLS). configure terminates with:
> config.status: creating intl/Makefile
> config.status: error: cannot find input file: intl/Makefile.in
> (Obviously - gettextize -f just wiped out intl/)

gettext, to be blunt, is crap.  There's essentially zero consistency
between releases.  raster has found a version that works, and until I
get around to building and installing that version, I'm kinda leaving
the gettext goop up to him.

So you don't need to worry about gettext or any of the other auto*
stuff too much.  We'll make sure it works. :)

> And thanks for accepting my stuff so far :-)

Thanks for sending good stuff. :-)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Grief and tragedy and hatred are only for a time.  Goodness,
  remembrance, and love have no end."      -- President George W. Bush

On Mon, Mar 31, 2003 at 12:35:36PM -0500, Michael Jennings wrote:
> On Sunday, 30 March 2003, at 23:03:06 (+0200),
> Kim Woelders wrote:
>=20
> > Here is yet another set of small patches for E16:
>=20
> Should be in CVS now.
>=20
> > I am having a lot of noise and trouble with the auto*
> > stuff again. "gettextize -f" (output attached) removes
> > and modifies things that are in CVS (e.g. intl/ and
> > ABOUT-NLS). configure terminates with:
> > config.status: creating intl/Makefile
> > config.status: error: cannot find input file: intl/Makefile.in
> > (Obviously - gettextize -f just wiped out intl/)
>=20
> gettext, to be blunt, is crap.  There's essentially zero consistency
> between releases.  raster has found a version that works, and until I
> get around to building and installing that version, I'm kinda leaving
> the gettext goop up to him.

Yeah, gettext is definitely crap, but what about the setup-gettext
script I wrote that was put into e17? (I don't know if it's still
there, actually?) It was designed for the gaim project, as we had many
people all using different combinations of gettext, automake, and
autoconf, and the script handled every one of their cases. Might be
worth a try.

Christian
=20
--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   Why does the person that snores always fall asleep first?

Hi again,

Yet another patch. This one sets the _NET_DESKTOP_VIEWPORT
hint correctly (one coordinate set per desktop).

/Kim

On Monday, 31 March 2003, at 14:03:26 (-0800),
Christian Hammond wrote:

> Yeah, gettext is definitely crap, but what about the setup-gettext
> script I wrote that was put into e17? (I don't know if it's still
> there, actually?) It was designed for the gaim project, as we had
> many people all using different combinations of gettext, automake,
> and autoconf, and the script handled every one of their cases. Might
> be worth a try.

Thanks Christian.  Worked like a charm.  I was able to do a "make
distcheck" that worked for the first time in ages. :-)

raster (and others):  If you have a moment, please update e16/e and
make sure "make distcheck" still passes for you as well (after running
autogen.sh, obviously).

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "The White House doesn't take American Express.  A briefcase full of
  unmarked bills:  It's everywhere you want to be."    -- Rona Bologna

What can I say...

This one gets _NET_DESKTOP_GEOMETRY set correctly when the desktop size 
is changed.

/Kim

Michael Jennings wrote:
> raster (and others):  If you have a moment, please update e16/e and
> make sure "make distcheck" still passes for you as well (after running
> autogen.sh, obviously).

$ ./autogen.sh
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autogen.sh command line.
Generating configuration files for Enlightenment, please wait....
   setup-gettext.sh
autopoint: *** Missing version: please specify in configure.in through a 
line 'AM_GNU_GETTEXT_VERSION(x.yy.zz)' the gettext version the package 
is using
autopoint: *** Stop.
   aclocal
--- snip ---
config.status: error: cannot find input file: intl/Makefile.in
=> Aaaargh!

OK, deleted "intl/Makefile" in configure.in:

$ ./autogen.sh
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autogen.sh command line.
Generating configuration files for Enlightenment, please wait....
   setup-gettext.sh
autopoint: *** Missing version: please specify in configure.in through a 
line 'AM_GNU_GETTEXT_VERSION(x.yy.zz)' the gettext version the package 
is using
autopoint: *** Stop.
   aclocal
--- snip ---
config.status: executing default commands

Now type 'make' to compile Enlightenment.

$ make distcheck
make: *** No rule to make target `ABOUT-NLS', needed by `distdir'.  Stop.
=> Aaaargh!

/Kim

* Kim Woelders (kim@...) [030402 18:29]:
> What can I say...

How come no one ran into the "bugs" before ?? :) 


Hall

On Thu, Apr 03, 2003 at 09:57:37PM +0200, Kim Woelders wrote:
> Michael Jennings wrote:
> >raster (and others):  If you have a moment, please update e16/e and
> >make sure "make distcheck" still passes for you as well (after running
> >autogen.sh, obviously).
>=20
> $ ./autogen.sh
> I am going to run ./configure with no arguments - if you wish
> to pass any to it, please specify them on the ./autogen.sh command line.
> Generating configuration files for Enlightenment, please wait....
>   setup-gettext.sh
> autopoint: *** Missing version: please specify in configure.in through a=
=20
> line 'AM_GNU_GETTEXT_VERSION(x.yy.zz)' the gettext version the package=20
> is using
> autopoint: *** Stop.
>   aclocal
> --- snip ---
> config.status: error: cannot find input file: intl/Makefile.in
> =3D> Aaaargh!

Setup-gettext should have been installed by typing ./setup-gettext
--install. Somewhere after AM_GNU_GETTEXT in configure.in, place
the line:
AM_GNU_GETTEXT_VERSION(0.10.40)

(The version number can really be anything, in my experience. It just
wants the macro to exist)

Christian

--=20
Christian Hammond         <>  The GNUpdate Project
chipx86@...      <>  http://www.gnupdate.org/
   Consider the daffodil. And while you're doing that, I'll be over here,
   looking through your stuff.
      -- Bill Austin

Hall Stevenson wrote:
> 
> How come no one ran into the "bugs" before ?? :) 
> 
Do I sense a trick question here?
Anyway, one explanation is as follows:
The last two small patches fix bugs that you would experience only if
1) you were playing with E16 from CVS.
2) had an external non-WM application that actually used the
    large desktop EWM hints, e.g. a pager.
    I'm not aware that any such application exists.
3) resized the desktop (last patch).
Not your average scenario.

This morning, however, large desktop support in libwnck-2.3 was comitted 
to CVS. This means that gnome-panel with pager and tasklist using a 
fresh libwnck will work nicely with E16 from CVS (and E-0.16.6 :-)).
In a GNOME+E16 scenario, someone used to having the large desktops would 
    more or less immediately notice if the _NET_DESKTOP_VIEWPORT thing 
hadn't been implemented correctly.

/Kim

Christian Hammond wrote:
> Setup-gettext should have been installed by typing ./setup-gettext
> --install. Somewhere after AM_GNU_GETTEXT in configure.in, place
> the line:
> AM_GNU_GETTEXT_VERSION(0.10.40)
> 
> (The version number can really be anything, in my experience. It just
> wants the macro to exist)

Thanks - now I can run ./autogen.sh and compile from a clean CVS 
checkout again :-)
The version number does matter, 1.2.3 was not good, 0.10.40 worked for me.

Is it possible to rsync(read) the CVS?

/Kim

Hi again,

Here is yet another patch with mostly EWMH related stuff.

e16/e:
- Added AM_GNU_GETTEXT_VERSION to e/configure.in to get things going,
   as suggested by Christian Hammond
- Hadn't set _NET_WM_NAME on the _NET_SUPPORTING_WM_CHECK window
- Implemented _NET_WM_WINDOW_TYPE_UTILITY (for epplets)
- Set never_use_area if _NET_WM_WINDOW_TYPE_DOCK
- Moved _WIN_DESKTOP_BUTTON_PROXY setup to gnome.c (with the other
   old GNOME stuff)

e16/epplets:
- Make epplets use EWM hints (any reason to set the old ones?)

/Kim

On Saturday, 05 April 2003, at 17:40:50 (+0200),
Kim Woelders wrote:

> >Setup-gettext should have been installed by typing ./setup-gettext
> >--install. Somewhere after AM_GNU_GETTEXT in configure.in, place
> >the line:
> >AM_GNU_GETTEXT_VERSION(0.10.40)
> >
> >(The version number can really be anything, in my experience. It just
> >wants the macro to exist)

You neglected to mention that.  Hopefully my latest commit will solve
the problem. :)

> e16/e:
> - Added AM_GNU_GETTEXT_VERSION to e/configure.in to get things going,
>   as suggested by Christian Hammond
> - Hadn't set _NET_WM_NAME on the _NET_SUPPORTING_WM_CHECK window
> - Implemented _NET_WM_WINDOW_TYPE_UTILITY (for epplets)
> - Set never_use_area if _NET_WM_WINDOW_TYPE_DOCK
> - Moved _WIN_DESKTOP_BUTTON_PROXY setup to gnome.c (with the other
>   old GNOME stuff)

It's in.

> e16/epplets:
> - Make epplets use EWM hints (any reason to set the old ones?)

Any reason not to?  I've left both sets of hints enabled unless
someone comes up with a compelling reason to do otherwise.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Don't you see what Watley is after?  Total joke-telling immunity!
  He's already got the big two religions covered.  If he ever gets
  Polish citizenship, there'll be no stopping him!"  -- Jerry Seinfeld

Hi,

I see we are still in -pre for E-0.16.6, so maybe there is still time
for a few more patches :-)

e16-hints-configinfo.patch is an attempt to shed a bit of light on
the use of --enable-hints-ewmh/gnome/kde.

e16-fix-gnome-dthint.patch removes a redundant setting of the
_WIN_AREA hint.

e16-fix-pager-update.patch gets the E pagers updated in a few cases
that weren't handled properly (try switching areas on a 2x2 area
desktop with only sticky windows).

e16-fix-desktop-switch.patch removes some redundancy from GotoDesktop
(things also done in RaiseDesktop) that generated quite a lot of "hint
noise".

/Kim

Hi,

I see these patches haven't gone into CVS. Have I used up my patch
quota, don't you like them, or did they just get lost?

As for further patches for e16 - There is a problem with windows being
de-iconfied that sometimes don't pop up where they should. I suspect I
introduced that problem, and I am looking into it.

People have problems installing E-0.16.6-pre? on RedHat systems.
In case anybody is interested, I have made some binary RPMs, see:
http://www.woelders.dk/~kw/stuff/e16/RPMS-Test/
It would be nice if the RPMs could be put somewhere else - my bandwidth
is not very large, and I will remove them if it becomes a problem.

/Kim

Kim Woelders wrote:
> Hi,
> 
> I see we are still in -pre for E-0.16.6, so maybe there is still time
> for a few more patches :-)
> 
> e16-hints-configinfo.patch is an attempt to shed a bit of light on
> the use of --enable-hints-ewmh/gnome/kde.
> 
> e16-fix-gnome-dthint.patch removes a redundant setting of the
> _WIN_AREA hint.
> 
> e16-fix-pager-update.patch gets the E pagers updated in a few cases
> that weren't handled properly (try switching areas on a 2x2 area
> desktop with only sticky windows).
> 
> e16-fix-desktop-switch.patch removes some redundancy from GotoDesktop
> (things also done in RaiseDesktop) that generated quite a lot of "hint
> noise".
> 
> /Kim
>

On Mon, 21 Apr 2003 16:59:52 +0200 Kim Woelders <kim@...> babbled:

> Hi,
> 
> I see these patches haven't gone into CVS. Have I used up my patch
> quota, don't you like them, or did they just get lost?

> As for further patches for e16 - There is a problem with windows being
> de-iconfied that sometimes don't pop up where they should. I suspect I
> introduced that problem, and I am looking into it.
> 
> People have problems installing E-0.16.6-pre? on RedHat systems.
> In case anybody is interested, I have made some binary RPMs, see:
> http://www.woelders.dk/~kw/stuff/e16/RPMS-Test/
> It would be nice if the RPMs could be put somewhere else - my bandwidth
> is not very large, and I will remove them if it becomes a problem.
> 
> /Kim
> 
> Kim Woelders wrote:
> > Hi,
> > 
> > I see we are still in -pre for E-0.16.6, so maybe there is still time
> > for a few more patches :-)
> > 
> > e16-hints-configinfo.patch is an attempt to shed a bit of light on
> > the use of --enable-hints-ewmh/gnome/kde.
> > 
> > e16-fix-gnome-dthint.patch removes a redundant setting of the
> > _WIN_AREA hint.
> > 
> > e16-fix-pager-update.patch gets the E pagers updated in a few cases
> > that weren't handled properly (try switching areas on a 2x2 area
> > desktop with only sticky windows).
> > 
> > e16-fix-desktop-switch.patch removes some redundancy from GotoDesktop
> > (things also done in RaiseDesktop) that generated quite a lot of "hint
> > noise".
> > 
> > /Kim
> > 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

On Mon, 21 Apr 2003 16:59:52 +0200 Kim Woelders <kim@...> babbled:

> Hi,
> 
> I see these patches haven't gone into CVS. Have I used up my patch
> quota, don't you like them, or did they just get lost?

no :) you just got on my "backlog" and no-one else has done the patch-applying
(my inbox has 307 mails in it left to REPLY to or deal with in some way (patch,
look at code,  etc.)). 

> As for further patches for e16 - There is a problem with windows being
> de-iconfied that sometimes don't pop up where they should. I suspect I
> introduced that problem, and I am looking into it.
> 
> People have problems installing E-0.16.6-pre? on RedHat systems.
> In case anybody is interested, I have made some binary RPMs, see:
> http://www.woelders.dk/~kw/stuff/e16/RPMS-Test/
> It would be nice if the RPMs could be put somewhere else - my bandwidth
> is not very large, and I will remove them if it becomes a problem.

there are some earlier pre rpm's on e's sf feed too.

> /Kim
> 
> Kim Woelders wrote:
> > Hi,
> > 
> > I see we are still in -pre for E-0.16.6, so maybe there is still time
> > for a few more patches :-)
> > 
> > e16-hints-configinfo.patch is an attempt to shed a bit of light on
> > the use of --enable-hints-ewmh/gnome/kde.
> > 
> > e16-fix-gnome-dthint.patch removes a redundant setting of the
> > _WIN_AREA hint.
> > 
> > e16-fix-pager-update.patch gets the E pagers updated in a few cases
> > that weren't handled properly (try switching areas on a 2x2 area
> > desktop with only sticky windows).
> > 
> > e16-fix-desktop-switch.patch removes some redundancy from GotoDesktop
> > (things also done in RaiseDesktop) that generated quite a lot of "hint
> > noise".
> > 
> > /Kim
> > 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615

Kim Woelders wrote:
> As for further patches for e16 - There is a problem with windows being
> de-iconfied that sometimes don't pop up where they should. I suspect I
> introduced that problem, and I am looking into it.
> 
I think I have it right now. The problem is that the Extended Window
Manager Hints don't have an equivalent to the desktop area (_WIN_AREA).
Therefore I think that window positions also for iconified windows have
to be propagated through the windows x,y coordinates (+ the viewport 
origin _NET_DESKTOP_VIEWPORT), which must change appropriately when the
viewport is changed.

e16-ewmh-fix-deiconify.patch should fix the problem, i.e. makes
de-iconified windows always appear on the current viewport.

e16-iconboxcheck.patch is a trivial NULL pointer check that I had to
introduce to avoid a SEGV during startup that suddenly kept occurring.
The real problem lies possibly elsewhere.

e16-fix-pager-update-2.patch avoids doing a lot of stuff when the
desktop is *not* changed in MoveEwinToDesktopAt.

/Kim

There is still some bug with E16...

-Some windows stay in gnome-task bar after being closed
-E menus appears in gnome-task bar
-E place windows on gnome-panel and it's so boring
-After a long time, switching virtual desktop with pager is slower...

Thx for your work ;)

GnuMdk wrote:
> There is still some bug with E16...
Please report the versions of E (pre?, cvs, ...) and of libwnck.
> 
> -Some windows stay in gnome-task bar after being closed
Could you provide exact steps to reproduce this?
I have seen this behavior, but as far as I remember only as a bug in 
libwnck. Try doing
$ xprop -root -f _NET_CLIENT_LIST 32x '$0+' _NET_CLIENT_LIST
If _NET_CLIENT_LIST contains the id of the closed window, the bug is in 
E, otherwise it is in libwnck.

> -E menus appears in gnome-task bar
I hadn't noticed this, will look at it.

> -E place windows on gnome-panel and it's so boring
If you want gnome-panel to always be on top, it should be possible to 
configure gnome-panel to be e.g. in layer 6 (in 
~/.enlightenment/...e_session-XXXXXX.snapshots.0, I think).
It could be considered to always place dock-type windows above others, 
but I didn't like that behavior.

> -After a long time, switching virtual desktop with pager is slower...
Is there any particular reason to believe that this has something to do 
with E?

> 
> Thx for your work ;)
Thanks for your feedback :-)
> 

/Kim

Kim Woelders wrote:
[snip]
I certainly don't want to presure you or anything but how close are we 
to coming out with an e.16 release?  I'm sure that releasing it, 
having us compile and install would increase the incidents of bug 
reports,  and generally help in your bug stomping efforts.

Or not.

Anyway,  just wanted to let you know that I'm interested in trying 
e.16.6 when you are ready to call it ready ... or whatever ;-)

-- 
Robert G. Werner
rwerner@...
2001/9/11

Fascinating, a totally parochial attitude.
		-- Spock, "Metamorphosis", stardate 3219.8

On Sun, 27 Apr 2003 16:07:35 +0200, GnuMdk said:

> -After a long time, switching virtual desktop with pager is slower...

Could this be the results of the 'Desktop Backgrounds Settings' value
for 'Unused backgrounds freed after hh:mm:ss'?  I'd not be surprised if
you have a desktop with a large/complex background that takes 2-3M of
storage, it gets released - and then the next time you visit that desktop
it goes 'oink' and gets all piggy because it has to allocate memory,
read it in, and blit it onto the screen (this last step can be *very*
painful if you don't have the SHM extension going...)

Also, the graphics card/driver *does* make a difference.  I'm using XFree 4.3.0
on a GeForce 440Go (which uses the NV17 core), and the NVidia binary driver
can load 2-3 1600x1200 backgrounds in well under a second, while the 'nv'
open-source driver takes 4-5 seconds for the same...

Robert G. Werner wrote:
> I certainly don't want to presure you or anything but how close are we 
> to coming out with an e.16 release?  I'm sure that releasing it, having 
> us compile and install would increase the incidents of bug reports,  and 
> generally help in your bug stomping efforts.
> 
> Or not.
> 
> Anyway,  just wanted to let you know that I'm interested in trying 
> e.16.6 when you are ready to call it ready ... or whatever ;-)
> 
Developers like the code to be properly tested before releasing, and you 
want a release so you can start testing ...hmmm... :-)
I guess that's why there is such a thing as pre-releases. Please do try 
these out and complain about whatever problems there are. The more 
people doing this, the sooner the a release will come out and the better 
it will be.

As for the state of the code, I can really only speak for the new hint 
stuff (GNOME2/KDE3 compatibility) that I have messed with.
-pre2 had an annoying problem with (de-)iconifying windows. This should
  be fixed in cvs (-pre3?).
The only problems that I am aware of are:
1) E-menu's temporarily occur in window lists (_NET_CLIENT_LIST).
2) The focus window is not updated properly in _NET_ACTIVE_WINDOW
    when switching desktops/viewports.
3) People see some segfaults that are believed to be caused by the
    new hint code. Unfortunately they seem to be hard to reproduce.

1-2) will show only if you are using an external pager/window list (e.g. 
gnome-panel). They are almost cosmetic, but I definitively think they 
should be fixed before a final release.
3) is obviously very annoying, and not something you want in a release.
Unfortunately I don't ever see E segfault (while running - there was a 
problem with iconboxes at startup).

I use E16.6 (from cvs) every day at work and at home, and it seems very 
stable to me. Everybody else will run E in a different environment and 
run in to all the bugs I never get to see.

There is one bug that I really would like to see fixed:
When switching the desktop, the window stacking is changed (sticky 
windows are raised above non-sticky).
But - I've not seen anybody else complain about this.

Bottom line: I think the best way to speed up the process is to try out 
the -pre's and report problems. It's impossible to fix bugs you don't 
know exist.

/Kim

On Mon, 28 Apr 2003 20:08:10 +0200, Kim Woelders said:

> There is one bug that I really would like to see fixed:
> When switching the desktop, the window stacking is changed (sticky 
> windows are raised above non-sticky).
> But - I've not seen anybody else complain about this.

Seeing that here too.  I've just not been ambitious enough to attack
the code and fix it...

I'll put out a pre3 in the next day or two...  but I don't think it's
worth shoving out a release that isn't ready.  besides this thing hasn't
been released in years, you can wait a few more weeks :)

--
Mandrake      (http://mandrake.net)
Cepstral, LLC (http://www.cepstral.com)

> -----Original Message-----
> From: enlightenment-devel-admin@... 
> [mailto:enlightenment-devel-admin@...] On 
> Behalf Of Robert G. Werner
> Sent: Sunday, April 27, 2003 9:02 PM
> To: Kim Woelders
> Cc: GnuMdk; enlightenment-devel
> Subject: Re: [E-devel] While we await E17...
> 
> 
> Kim Woelders wrote:
> [snip]
> I certainly don't want to presure you or anything but how 
> close are we 
> to coming out with an e.16 release?  I'm sure that releasing it, 
> having us compile and install would increase the incidents of bug 
> reports,  and generally help in your bug stomping efforts.
> 
> Or not.
> 
> Anyway,  just wanted to let you know that I'm interested in trying 
> e.16.6 when you are ready to call it ready ... or whatever ;-)
> 
> -- 
> Robert G. Werner
> rwerner@...
> 2001/9/11
> 
> Fascinating, a totally parochial attitude.
> 		-- Spock, "Metamorphosis", stardate 3219.8
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

For the task bar, i've found the problem, i've two gnome-panel and the 
window that i see in gnome-task is the second panel...

For the placement of windows, i'm not speeking of a windows being on 
top but the way E place window on desktop....
For exemple, if i run balsa or galeon(programs that remembers their 
size), E place this new window on gnome panel. I can move this window 
to it good place but it's so boaring... If i remember, with gnome-1.4, 
E never place window on gnome-panel...
I will send you screenshot for see my probleme: t.jpg is how E place 
window, t2.jpg is how E should place window...

Continue you're good job :)


Le 2003.04.27 17:34, Kim Woelders a écrit :
> GnuMdk wrote:
>> There is still some bug with E16...
> Please report the versions of E (pre?, cvs, ...) and of libwnck.
>> 
>> -Some windows stay in gnome-task bar after being closed
> Could you provide exact steps to reproduce this?
> I have seen this behavior, but as far as I remember only as a bug in 
> libwnck. Try doing
> $ xprop -root -f _NET_CLIENT_LIST 32x '$0+' _NET_CLIENT_LIST
> If _NET_CLIENT_LIST contains the id of the closed window, the bug is 
> in E, otherwise it is in libwnck.
> 
>> -E menus appears in gnome-task bar
> I hadn't noticed this, will look at it.
> 
>> -E place windows on gnome-panel and it's so boring
> If you want gnome-panel to always be on top, it should be possible to 
> configure gnome-panel to be e.g. in layer 6 (in 
> ~/.enlightenment/...e_session-XXXXXX.snapshots.0, I think).
> It could be considered to always place dock-type windows above 
> others, but I didn't like that behavior.
> 
>> -After a long time, switching virtual desktop with pager is slower...
> Is there any particular reason to believe that this has something to 
> do with E?
> 
>> 
>> Thx for your work ;)
> Thanks for your feedback :-)
>> 
> 
> /Kim
>

Kim Woelders said:
>
> 3) People see some segfaults that are believed to be caused by the
>     new hint code. Unfortunately they seem to be hard to reproduce.

It may just be me, but I segfault 100% of the time when trying
to remember window settings or trying to enable kde support through
the settings manager.  I'm stuck with all default window borders
and such as E16 dies whenever I try to 'remember' any new settings.

And it does this whether window manager hints are compiled in or not.
I can't figure it out, I'm just coping with it ;)

Kim Woelders wrote:
[snip]
Didn't mean to pressure anyone.  I just was hoping there was a better
place than CVS to pull down the new code and try it.  I found your
srpms (again) and was pulling them but they were coming slow,  I was
afraid I'd eat all your bandwidth,  and decided to stop and go home
instead.

Has anyone felt brave enough to tackle the Epplets launching multiple
copies on restart?  Raster made it sound like fixing that would
require a major re-model.  Is there any band-aid style work we could do?

Was someone planning on doing a new release of the epplets?  I'd like
to see E-CPU2 replace the earlier one.

Also,  how does E find the stuff it puts in the GNOME menus?  Does it
need updating?

Don't mean to sound whiny.  I'll look into either pulling the CVS
tomorrow or finding the SRPMs of the pre-s somewhere else.

Thanks for all your work and making sure that those of us who aren't
ready to live on the wild edge of E.17 development still have a nice WM.
-- 
Robert G. Werner
rwerner@...
2001/9/11

Fascinating, a totally parochial attitude.
		-- Spock, "Metamorphosis", stardate 3219.8

"Robert G. Werner" wrote:
> 
> 
> Kim Woelders wrote:
> [snip]
> Didn't mean to pressure anyone.  I just was hoping there was a better
> place than CVS to pull down the new code and try it.  I found your
> srpms (again) and was pulling them but they were coming slow,  I was
> afraid I'd eat all your bandwidth,  and decided to stop and go home
> instead.

Um, this seems kind of obvious, but since you don't actually say...

Why aren't you pulling these from sourceforge?

http://sourceforge.net/project/showfiles.php?group_id=2

They've got some bandwidth.

-- 
Kevin

Kevin Brosius wrote:
[snip]
> Um, this seems kind of obvious, but since you don't actually say...
> 
> Why aren't you pulling these from sourceforge?
> 
> http://sourceforge.net/project/showfiles.php?group_id=2
> 
> They've got some bandwidth.
> 
Sorry,  I didn't make it clear.
Kim has the latest patches on a personal website.  They haven't been 
posted to source forge.  I wasn't going to pull the CVS because I 
wasn't planing on building my own.

Anyway,  Kim let me know that there was plety of bandwidth so I just 
pulled the srpms from there.

-- 
Robert G. Werner
rwerner@...
2001/9/11

Fascinating, a totally parochial attitude.
		-- Spock, "Metamorphosis", stardate 3219.8

vallimar@... wrote:
> Kim Woelders said:
> 
>>3) People see some segfaults that are believed to be caused by the
>>    new hint code. Unfortunately they seem to be hard to reproduce.
> 
> 
> It may just be me, but I segfault 100% of the time when trying
> to remember window settings or trying to enable kde support through
> the settings manager.  I'm stuck with all default window borders
> and such as E16 dies whenever I try to 'remember' any new settings.
> 
> And it does this whether window manager hints are compiled in or not.
> I can't figure it out, I'm just coping with it ;)

Could this be something with incorrectly compiled/installed localization 
stuff?
Try starting E with LANG=Bogus, I believe it then falls back to defaults.

/Kim

Robert G. Werner wrote:
> Sorry,  I didn't make it clear.
> Kim has the latest patches on a personal website.  They haven't been 
> posted to source forge.  I wasn't going to pull the CVS because I wasn't 
> planing on building my own.
> 
> Anyway,  Kim let me know that there was plety of bandwidth so I just 
> pulled the srpms from there.
> 
Actually, the only thing I have there that is not on SF is a binary RPM
for RH8/9 built from the -pre2 tarball on SF (+an fnlib RPM for RH8/9).

When -pre3 is released I will be happy to supply a binary RH8/9 RPM, but 
again, I would prefer it not to be on my site.

/Kim

On Mon, 2003-04-28 at 14:08, Kim Woelders wrote:

> The only problems that I am aware of are:
> 1) E-menu's temporarily occur in window lists (_NET_CLIENT_LIST).
> 2) The focus window is not updated properly in _NET_ACTIVE_WINDOW
>     when switching desktops/viewports.
> 3) People see some segfaults that are believed to be caused by the
>     new hint code. Unfortunately they seem to be hard to reproduce.
I'd like to add a fourth...
the X cursors in X 4.3 do strange things in e (I'm running 16.6pre2),
even within the same window. For instance right now in evolution, in the
frame showing the message, I have a pretty whiteglass cursor, in the
message thread and folder list I have the old ugly cursor. I've tried
messing around disabling the cursor.cfg and what not in themes but it
doesn't seem to help...Not sure what could be causing it.

I've also had a few segfaults when enabling sounds in e, but I'm almost
positive it's a theme issue.

Ryan

On Thu, 1 May 2003, Ryan wrote:

> the X cursors in X 4.3 do strange things in e (I'm running 16.6pre2),
> even within the same window. For instance right now in evolution, in the
> frame showing the message, I have a pretty whiteglass cursor, in the
> message thread and folder list I have the old ugly cursor. I've tried
> messing around disabling the cursor.cfg and what not in themes but it
> doesn't seem to help...Not sure what could be causing it.

Removing the cursors.cfg file will not enable the new Xcursors
that X has available, you have to modify the cursors.cfg file
and remap the cursors to the native_id's as they are defined
in <definiitions>  look for all the XC_* defines.  This will
allow E to use the new Xcursors assuming you have X setup to
use them.

I'm having an odd problem with 16.2 pre2, I built an rpm package for mdk
9.1 using the pre2 sources, on two boxes evything seems fine, on a third
identical setup, when switching themes sometimes the fonts become
entirely garbled in menus, tooltips, window titles, etc. and the only
way to clear the problem is to remove ~/.enlightenment

For example, the main menu displays:
5ser[]ENUS
$ESKTOP
3ETTINGS
4HEMES
-AINTENANCE
(ELP
!BOUT%LIGHTENMENT
etc..

All three systems have identical esetups as far as fonts, freetype, and
fnlib go. Anyone have any idea whre else to look for the problem?

Ryan

Another problem with gnome2.3!!!!!!

Panels don't remember their position, they are always at bottom of the 
screen...

It's not a gnome bug, it works with metacity but not with E and sawfish!

GnuMdk wrote:
> Another problem with gnome2.3!!!!!!
> 
> Panels don't remember their position, they are always at bottom of the 
> screen...
> 
> It's not a gnome bug, it works with metacity but not with E and sawfish!
> 
I just tried on RH-8.0:
$ WINDOW_MANAGER=enlightenment gnome-session

I get two gnome-panels (one at top and one at bottom) and all looks OK.
Maybe you have some saved settings for gnome-panel?

/Kim

GnuMdk wrote:
> For the placement of windows, i'm not speeking of a windows being on top 
> but the way E place window on desktop....
> For exemple, if i run balsa or galeon(programs that remembers their 
> size), E place this new window on gnome panel. I can move this window to 
> it good place but it's so boaring... If i remember, with gnome-1.4, E 
> never place window on gnome-panel...
> I will send you screenshot for see my probleme: t.jpg is how E place 
> window, t2.jpg is how E should place window...

I just comitted some changes that may solve this problem.
I would appreciate if you could try it out.

/Kim

It works, thanx for your great job ;)


On 2003.05.16 20:24, Kim Woelders wrote:
> GnuMdk wrote:
>> For the placement of windows, i'm not speeking of a windows being on 
>> top but the way E place window on desktop....
>> For exemple, if i run balsa or galeon(programs that remembers their 
>> size), E place this new window on gnome panel. I can move this 
>> window to it good place but it's so boaring... If i remember, with 
>> gnome-1.4, E never place window on gnome-panel...
>> I will send you screenshot for see my probleme: t.jpg is how E place 
>> window, t2.jpg is how E should place window...
> 
> I just comitted some changes that may solve this problem.
> I would appreciate if you could try it out.
> 
> /Kim
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise 
> solutions
> http://www.enterpriselinuxforum.com
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Another bug in E16.

When you set fullscreen for a window with E16, it works well but when 
you leave fullscreen, E16 doesn't go to original resolution.
It works with previous X version...

[gnumdk@... gnumdk]$ rpm -q XFree86
XFree86-4.3-8mdk
[gnumdk@... gnumdk]$