[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    Re: Network Management Applet not working
From:       Ruediger Gad <r.c.g () gmx ! de>
Date:       2013-06-01 12:25:33
Message-ID: 51A9E83D.2060408 () gmx ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On 05/31/2013 12:38 PM, Ruediger Gad wrote:
> On 05/30/2013 07:18 PM, Marco Martin wrote:
> > On Thursday 30 May 2013, Ruediger Gad wrote:
> > 
> > > Marco also suggested to create a small sample app to try different
> > > combinations of windows flags and how they affect the behavior.
> > > Unfortunately, I do not have the time to write such an app right now but
> > > I found something that may be useful:
> > > http://qt-project.org/doc/qt-4.8/widgets-windowflags.html
> > > This app seems to be pretty much what Marco suggested?
> > > 
> > > Do you have any ideas where window flags may be set for applets in the
> > > top bar or the corresponding popups?
> > > Generally, do you have ideas on how to solve the issue?
> > 
> > another hack that came to mind, is patching popupapplet.cpp, and
> > making all
> > popup windows fullscreen (maximized, maybe even without alpha
> > channel,extra
> > kwin atoms and so forth)
> > 
> > for small screens it could even look it makes sense, so not "feel" as
> > such and
> > hack
> > 
> 
> Thanks for the hints and ideas Marco. :)
> 
> As you already mentioned in the other thread, the problem is really
> weird indeed.
> 
> 
> I'll try to summarize what I tested so far:
> 
> My first thought was that events get not forwarded properly to the
> popup, so I placed debug output in the event handler methods in
> dialog.cpp and popupapplet.cpp.
> With this debug output I could not find any difference between the
> non-working networkmanagement applet and the working battery applet.
> 
> The next try was to see whether the bounding box etc. are properly set.
> Again, everything seems fine here as well; no apparent difference
> between the two applets.
> 
> Another try I did some days ago was to simply put a big MouseArea in the
> top item of the NMPopup.qml code to see if, generally, mouse events
> reach the widget. Here, I couldn't get any events at all. I even set the
> z property to something insanely high like 1001.
> 
> 
> So, to summarize, it seems like the events get lost somewhere in the
> stack. In dialog.cpp and popupapplet.cpp it looked like that they are
> there (I was looking for mousePressEvent). But then they seem to get
> lost somewhere after that.
> 
> 
> 

Alright, I think I'll throw in the towel for now.

For some reason dialog.cpp receives mouse press events but the actual 
NMPopup.qml doesn't.
In the meantime I also tried various settings like setAcceptTouchEvents 
or grabMouse but with no success.

My last debug output attempts can be found here:
https://build.merproject.org/package/show?package=NetworkManager-kde&project=home%3Awonko%3Apa-networkmanagement-tests
 https://build.merproject.org/project/show?project=home%3Awonko%3Abranches%3Akde%3Adevel%3Aux
 Be aware that this is quite a mess. Even the patches are named stupidly.

As workaround I'll use nmcli for now. Connecting to a WPA wlan via nmcli 
is actually pretty straight forward (as mer user):
nmcli wifi connect "SSID" password "PASSWORD"

I hope someone else has more success on this one...


> 
> 
> 
> _______________________________________________
> Active mailing list
> Active@kde.org
> https://mail.kde.org/mailman/listinfo/active
> 


-- 
http://ruedigergad.com


["smime.p7s" (application/pkcs7-signature)]

_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active


[prev in list] [next in list] [prev in thread] [next in thread]