From: Robert G. W. <rw...@mi...> - 2003-04-28 01:02:16
|
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 rw...@ma... 2001/9/11 Fascinating, a totally parochial attitude. -- Spock, "Metamorphosis", stardate 3219.8 |
From: Kim W. <ki...@wo...> - 2003-04-28 18:08:24
|
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 |
From: <val...@se...> - 2003-04-29 07:22:47
|
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 ;) |
From: Kim W. <ki...@wo...> - 2003-04-30 05:15:44
|
val...@se... 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 |
From: Robert G. W. <rw...@mi...> - 2003-04-30 01:08:31
|
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 rw...@ma... 2001/9/11 Fascinating, a totally parochial attitude. -- Spock, "Metamorphosis", stardate 3219.8 |
From: Kevin B. <co...@co...> - 2003-04-30 02:18:09
|
"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 |
From: Robert G. W. <rw...@mi...> - 2003-04-30 02:35:40
|
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 rw...@ma... 2001/9/11 Fascinating, a totally parochial attitude. -- Spock, "Metamorphosis", stardate 3219.8 |
From: Kim W. <ki...@wo...> - 2003-04-30 07:14:45
|
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 |
From: Ryan <rli...@co...> - 2003-05-01 04:34:29
|
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 |
From: Vallimar <val...@se...> - 2003-05-01 16:18:33
|
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. |
From: GnuMdk <gn...@wa...> - 2003-05-03 12:50:27
|
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! |
From: Kim W. <ki...@wo...> - 2003-05-04 22:09:47
|
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 |
From: <Val...@vt...> - 2003-04-28 18:23:46
|
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... |
From: Geoff H. \(Mandrake\) <man...@ce...> - 2003-04-28 20:22:47
|
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: enl...@li... > [mailto:enl...@li...] 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 > rw...@ma... > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: GnuMdk <gn...@wa...> - 2003-04-28 23:00:04
|
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 > |
From: Kim W. <ki...@wo...> - 2003-05-16 18:24:53
|
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 |
From: GnuMdk <gn...@wa...> - 2003-05-17 15:38:23
|
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 > www.enterpriselinuxforum.com > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: GnuMdk <gn...@wa...> - 2003-05-18 20:54:34
|
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@cassiope gnumdk]$ rpm -q XFree86 XFree86-4.3-8mdk [gnumdk@cassiope gnumdk]$ |
From: <Val...@vt...> - 2003-04-28 02:11:57
|
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... |
From: Kim W. <ki...@wo...> - 2003-04-02 21:47:00
Attachments:
e16-ewmh-fix-viewport-hint.patch
|
Hi again, Yet another patch. This one sets the _NET_DESKTOP_VIEWPORT hint correctly (one coordinate set per desktop). /Kim |
From: Kim W. <ki...@wo...> - 2003-04-02 23:10:34
Attachments:
e16-fix-ewmh-desktop-resize.patch
|
What can I say... This one gets _NET_DESKTOP_GEOMETRY set correctly when the desktop size is changed. /Kim |
From: Hall S. <hal...@mi...> - 2003-04-03 23:08:51
|
* Kim Woelders (ki...@wo...) [030402 18:29]: > What can I say... How come no one ran into the "bugs" before ?? :) Hall |
From: Kim W. <ki...@wo...> - 2003-04-04 16:03:54
|
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 |
From: Ryan <rli...@co...> - 2003-05-02 02:52:22
|
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 |
From: Kim W. <ki...@wo...> - 2003-03-21 23:48:02
|
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 |