headers
jochen | 1 Sep 2005 01:06
Picon

[E-devel] synaptic windows

Hi guys,
I encountered a kind of weird think with synaptic debians gui for apt.
when synaptic creates a dialog window, eg the summary window when
applying changes, it does not show up in the ALT-TAB windowlist. However
it shows up in the menu window list. Now I don't know if this is
actually e's problem or a synaptic one. I had a look at the xprops of
both windows but as I don't really know anything about the net wm
specifications I could not make much out of it. Does _NET_WM_STATE(ATOM)
= _NET_WM_STATE_MODAL, _NET_WM_STATE_SKIP_TASKBAR
cause e to ignore it in the ALT-TAB list? It is quite annoying however,
as when the dialog pops up and I move my mouse I can't get the window to
the front without moving the main synaptic window. If it is a problem
with synaptic setting the wrong window properties could you tell me what
is causing this behavior so I can go take it up with them?
Cheers
Jochen
attached the window properties of the main synaptic window and the dialog
Attachment (synaptic_dialog_xprops.log): text/x-log, 21 KiB
Attachment (synaptic_xprops.log): text/x-log, 21 KiB
Permalink | Reply | 2 comments |
headers
Carsten Haitzler | 1 Sep 2005 01:38
Favicon
Gravatar

Re: [E-devel] e segfault

On Thu, 01 Sep 2005 10:20:52 +1200 jochen <jochen.schroeder <at> gmail.com> babbled:

> Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 31 Aug 2005 14:08:34 +1200 jochen <jochen.schroeder <at> gmail.com>
> > babbled:
> > 
> > 
> >>I just had e segfault on me. Unfortunatly I don't really now what I did
> >>when it happened I was working with glade-2. Well here is the backtrace
> >>anyway. If it happens again I'll try to pay a little more attention to
> >>what I did.
> >>Cheers
> >>Jochen
> > 
> > 
> > are you using any modules other than those in e17's tree (not e_modules, not
> > engage etc.) if you are - disable them. do u have moduels in ~/.e/e/modules
> > you once put ther or compiled? remove them. i suspect you have a moduel
> > built against older headers or something similar. try a make clean
> > distclean and rebuild of e.
> > 
> >
> I just had rebuild all of e 3 or 4 days ago, just checked my logs
> everything build fine, so I don't think it linked against older libs. I
> use installwatch to uninstall all packages first. I was using monitor
> and engage modules, if I manage to reproduce the segv I try if they were
> the coulprits and let you know.
> Cheers
> Jochen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Haitzler | 1 Sep 2005 01:41
Favicon
Gravatar

Re: [E-devel] Edje: Gradients and Lines ?

On Wed, 31 Aug 2005 21:38:53 +0200 "Michael 'Mickey' Lauer"
<mickey <at> tm.informatik.uni-frankfurt.de> babbled:

> Hi,
> 
> is there any special reason except "no one needed/coded them yet" for
> Gradients and Lines being unavailable as Edje parts? I for one would
> think especially gradients would be pretty helpful.

i had no use for them, thus didnt support them. they would need lots of
metadata defining the gradient, angle, line endpoints etc. the gradient object
is limtied in that it fills a rectangle with a gradient - that's it. lines are
well non-anti-aliased ugly lines. very little use for them imho. thus they
havent been put into edje. same as polygon objects.

> -- 
> Regards,
> 
> Mickey.
> ------------------------------------------------------------------
> Dipl.-Inf. Michael 'Mickey' Lauer <mickey <at> tm.cs.uni-frankfurt.de>
> ------------------------------------------------------------------
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carsten Haitzler | 1 Sep 2005 01:28
Favicon
Gravatar

Re: [E-devel] ERROR: file '/usr/bin/Eterm' contains a standard rpath '/usr/lib' in [/usr/lib:/ usr/lib/Eterm] on FC4

On Wed, 31 Aug 2005 18:08:01 -0400 Mike Frysinger <vapier <at> gentoo.org> babbled:

> On Wednesday 31 August 2005 10:23 am, Michael Jennings wrote:
> > On Wednesday, 31 August 2005, at 01:43:47 (-0400),
> >
> > Mike Frysinger wrote:
> > > it makes a difference to us distro maintainers who wish to remove it
> >
> > To what end?  What do you hope to accomplish?  What does removing it
> > gain you that makes it worth the effort (not to mention the added
> > configure/Makefile cruft)?
> 
> well, as you can see, some distro's like to clamp down on RPATH's (for 
> whatever reasons/policies/boredom)
> 
> so Eterm is going to be changed, it'd just be nice if we could do it with a 
> simple ./configure option rather than patching it ourselves ;)
> -mike

but what is  the REASON for this rpath removal policy? i'm curious to know why!
i'm wondering how it causes problems or breaks things or such... ? i'd really
like to know! :)

--

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster <at> rasterman.com
裸好多                              raster <at> deephackmode.org
Tokyo, Japan (東京 日本)

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 4 comments |
headers
Carsten Haitzler | 1 Sep 2005 01:48
Favicon
Gravatar

Re: [E-devel] synaptic windows

On Thu, 01 Sep 2005 11:06:50 +1200 jochen <jochen.schroeder <at> gmail.com> babbled:

> Hi guys,
> I encountered a kind of weird think with synaptic debians gui for apt.
> when synaptic creates a dialog window, eg the summary window when
> applying changes, it does not show up in the ALT-TAB windowlist. However
> it shows up in the menu window list. Now I don't know if this is
> actually e's problem or a synaptic one. I had a look at the xprops of
> both windows but as I don't really know anything about the net wm
> specifications I could not make much out of it. Does _NET_WM_STATE(ATOM)
> = _NET_WM_STATE_MODAL, _NET_WM_STATE_SKIP_TASKBAR
> cause e to ignore it in the ALT-TAB list? It is quite annoying however,
> as when the dialog pops up and I move my mouse I can't get the window to
> the front without moving the main synaptic window. If it is a problem
> with synaptic setting the wrong window properties could you tell me what
> is causing this behavior so I can go take it up with them?
> Cheers
> Jochen
> attached the window properties of the main synaptic window and the dialog

the ski taskbar property is what is causing e to not include it in the winlist.
the middle click window list is kind of a hack until we have a proper
taskbar... where it will be skipped too because synaptic is asking for it to
be. basically i'm equating the alt-tab list with a taskbar that is btought up
on demand in a popup and lets u run through it in order of most recently
focused window to least recentyl focused. thats why it skips it. because
synaptic asked e to (and e is doing what it was asked). skip taskbar windows
are often ones that have no real need to be switched to by a task switcher
mechanism - the app decides this as the wm has no idea what the contents of
that window are - so the "app knows best" is the position here, so i would take
(Continue reading)

Permalink | Reply | 1 comment |
headers
jochen | 1 Sep 2005 02:09
Picon

Re: [E-devel] synaptic windows

Carsten Haitzler (The Rasterman) wrote:
> On Thu, 01 Sep 2005 11:06:50 +1200 jochen <jochen.schroeder <at> gmail.com> babbled:
> 
> 
>>Hi guys,
>>I encountered a kind of weird think with synaptic debians gui for apt.
>>when synaptic creates a dialog window, eg the summary window when
>>applying changes, it does not show up in the ALT-TAB windowlist. However
>>it shows up in the menu window list. Now I don't know if this is
>>actually e's problem or a synaptic one. I had a look at the xprops of
>>both windows but as I don't really know anything about the net wm
>>specifications I could not make much out of it. Does _NET_WM_STATE(ATOM)
>>= _NET_WM_STATE_MODAL, _NET_WM_STATE_SKIP_TASKBAR
>>cause e to ignore it in the ALT-TAB list? It is quite annoying however,
>>as when the dialog pops up and I move my mouse I can't get the window to
>>the front without moving the main synaptic window. If it is a problem
>>with synaptic setting the wrong window properties could you tell me what
>>is causing this behavior so I can go take it up with them?
>>Cheers
>>Jochen
>>attached the window properties of the main synaptic window and the dialog
> 
> 
> the ski taskbar property is what is causing e to not include it in the winlist.
> the middle click window list is kind of a hack until we have a proper
> taskbar... where it will be skipped too because synaptic is asking for it to
> be. basically i'm equating the alt-tab list with a taskbar that is btought up
> on demand in a popup and lets u run through it in order of most recently
> focused window to least recentyl focused. thats why it skips it. because
> synaptic asked e to (and e is doing what it was asked). skip taskbar windows
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Frysinger | 1 Sep 2005 04:14
Picon
Favicon
Gravatar

Re: [E-devel] imlib2: Cygwin build patch

On Wednesday 31 August 2005 05:44 pm, Yaakov S wrote:
> Mike Frysinger wrote:
> >>* src/lib/Makefile.am, src/modules/filters/Makefile.am,
> >>src/modules/loaders/Makefile.am:
> >>	add '-no-undefined' to *_la_LDFLAGS;
> >
> > whats the point of this ?
>
> If this is absent, libtool refuses to build shared libraries on Cygwin,
> where all symbols must be resolved at link time.

ld manpage seems to indicate opposite behavior here for the '-no-undefined' 
flag ...

does the flag '--allow-shlib-undefined' work ?

> >>* src/lib/dynamic_filters.c, src/lib/image.c:
> >>	RTDL_LOCAL is not defined on Cygwin;
> >
> > then wouldnt the somewhat sane thing be to put this in an internal header
> > file:
> > #ifndef RTLD_LOCAL
> > # define RTLD_LOCAL 0
> > # warning "your crap box doesnt define RTLD_LOCAL !?"
> > #endif
>
> If that's how you'd rather deal with it, fine.

find attached a patch for this then, please test :)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Sebastian Dransfeld | 1 Sep 2005 04:50
Picon
Picon

Re: [E-devel] imlib2: Cygwin build patch


>>>>	#ifndef __imlib_TrimLoaderList, since with it in Cygwin, imlib2 	can't
>>>>find the modules
>>>
>>>going by the comment, this looks like a bug in cygwin ?  what files does
>>>it consult if you try to do dlopen("libfoo") ?
>>
>>In Cygwin, the imlib2 modules are called bumpmap.dll, colormod.dll,
>>bmp.dll, etc.  In addition, there are corresponding .dll.a import
>>libraries and .la libtool files in the same directory.
> 
> 
> then why not fix __imlib_TrimLoaderList ?  i dont have cygwin to test against, 
> but what if you change the ".so" test in that func to ".dll" ?

Isn't it a possibility to switch to lt_dlopen etc.? They should be portable.

Sebastian

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 2 comments |
headers
Mike Frysinger | 1 Sep 2005 04:51
Picon
Favicon
Gravatar

Re: [E-devel] imlib2: Cygwin build patch

On Wednesday 31 August 2005 10:50 pm, Sebastian Dransfeld wrote:
> >>>>	#ifndef __imlib_TrimLoaderList, since with it in Cygwin, imlib2 	can't
> >>>>find the modules
> >>>
> >>>going by the comment, this looks like a bug in cygwin ?  what files does
> >>>it consult if you try to do dlopen("libfoo") ?
> >>
> >>In Cygwin, the imlib2 modules are called bumpmap.dll, colormod.dll,
> >>bmp.dll, etc.  In addition, there are corresponding .dll.a import
> >>libraries and .la libtool files in the same directory.
> >
> > then why not fix __imlib_TrimLoaderList ?  i dont have cygwin to test
> > against, but what if you change the ".so" test in that func to ".dll" ?
>
> Isn't it a possibility to switch to lt_dlopen etc.? They should be
> portable.

imlib2 used to utilize libtool but that support was ripped out iirc ... raster 
would know for sure :)
-mike

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 0 comments |
headers
Carsten Haitzler | 1 Sep 2005 05:31
Favicon
Gravatar

Re: [E-devel] imlib2: Cygwin build patch

On Thu, 01 Sep 2005 04:50:13 +0200 Sebastian Dransfeld <sebastid <at> stud.ntnu.no>
babbled:

> 
> >>>>	#ifndef __imlib_TrimLoaderList, since with it in Cygwin, imlib2
> >>>>	#	can't
> >>>>find the modules
> >>>
> >>>going by the comment, this looks like a bug in cygwin ?  what files does
> >>>it consult if you try to do dlopen("libfoo") ?
> >>
> >>In Cygwin, the imlib2 modules are called bumpmap.dll, colormod.dll,
> >>bmp.dll, etc.  In addition, there are corresponding .dll.a import
> >>libraries and .la libtool files in the same directory.
> > 
> > 
> > then why not fix __imlib_TrimLoaderList ?  i dont have cygwin to test
> > against, but what if you change the ".so" test in that func to ".dll" ?
> 
> Isn't it a possibility to switch to lt_dlopen etc.? They should be portable.

i moved away from litdl because if it adding dependencies and pain and not
actually providing any benefits - it is no porportable than dlopen EXCEPT where
it in theory can load moduels where a system can't do shared libraries (it can
compile them in) but we dont use ltdl in a way where this would ever work as we
need the actual files listed. so i moved back to dlopen - any system that
doesnt do dlopen likely is just not capable of the rest of the stuff we need
anyway :)

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane