Re: [Deskbar] X Grab

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2006/5/21, Raphael Slinckx <raphael slinckx net>:

On Sat, 2006-05-20 at 20:56 +0200, Mikkel Kamstrup Erlandsen wrote:
> 2006/5/20, Raphael Slinckx <raphael slinckx net>:

>
> It should be easily adaptable.  In the refactored code each UI has the
> focus/layout logic completely isolated.
>
> Maybe they can be embedded as convience methods in the
> CuemiacLayoutProvider abstract class (see
> ui/cuemiac/CuemiacLayoutProvider.py).

Hi !

I have a working hack with my code hooked into your refactored code.
It's a huge hack but it works.

I think it will require quite a massive approach change to be merged
correctly..

*gulp*

My approach is to subclass CuemiacEntry in CuemiacPopupEntry. It is an
entry that also has a private popup window that does all the focus magic
et co.

So this doesn't fit quite well in the code, since the code assumes in
multiple places that the entry and the popup are two distinct entities
with focus behavior between the two.

This was very deliberate (separating view and entry). I wanted to ensure maximum flexibilty with regards to future uis and layouts.

For gtk.EntryCompletion the compound design is ok, but we need quite a bit more functionality, and I fear we might end up with one mega do-it-all widget..?
 

Could you arrange that in your refactoring ?
Here is the API i used:
class CuemiacPopupEntry(CuemiacEntry):
  def __init__(self, default_icon, treeview, applet):
    CuemiacEntry.__init__(default_icon)

I'm not totally objecting to a design like this, but I have my doubts about the feasibilty design wise.
 

Treeview is the cuemiac treeview (the popup must have it to tweak the
selection cursor), the default_icon is the same as used in Cuemiac
Entry, and applet is needed bexause i re-use the CuemiacAlignedWindow
that requires the applet to be around..
This can be changed of course, if needed.

I don't know if i'm clear here ?
Quick summary: remova all places where separate entry/treeviewpopup are
assumed, and encapsulate the entry+popup in one single class (that i've
done) and adapt existing code accordingly. (that means no more
grab_focus and focus-out-event and such, all focus is inside that class)

I think the problem with this is actually that it obsoletes my entire design; separating all layout/focus logic into one class, which is used as a template by the CuemiacUIManager.

A compound widget like CuemiacPopupEntry is sort of against that idea at a fundamental level. And I must say that I really like the idea of decoupled classes.

Atleast a compound widget is against the principle of "loose coupling and strong cohesion"[1] - at least it appears to me :-P I'm no expert though.

I think we need a bit of discussion before we proceed much further :-)

Cheers,
Mikkel

[1]: Loose coupling = Classes objects should be largely independant on each other
Strong cohesion = Each class (and method for that matter) should do one thing - not multiple.

PS: I just checked the last two remaining issues I had on my todo list for full functionality (withuot regressions). So for that matter  - the cuemiac is refactored (with testing badly needed still).