Re: [Deskbar] X Grab

[Raphael Slinckx <raphael slinckx net>]

Hi !

It was late yesterday i realize what i wrote was.. not really
understandable :)


> 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..?

What i didn't explain properly is that this "mega-widget" which is
nearly like the gtkEntryCompletion, but stripped down, would be a
superset of both entriac and cuemiac.

Your separation of UI/Core is still needed and must remain in place, but
the entry/popup separation for the cuemiac was mostly made for technical
reasons, not for allowing greater flexibility (or I don't see how ?)

With this approach, the entriac would mean just adding this
EntryPopupWidget to the applet directly, and fot the button mode it
would mean to embed it in another popup, so you have the buttons in the
panel, then the opup which contains the EntryOpupWidget.

No more code duplication, and minimal entriac/cuemiac differences
(essentially the button-in-panel code for cuemiac and that's about it).

Now i look at Sebastian's work on standalone window. There's the
entry/popup (in this case it doesn't popup) in a single window, but in
different widget. I understand that this is the kind of flexibility you
mentioned before ?

So, after all i think some IRC discussion must happen so we can clearly
explain each other our views of the stuff :)

> 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.

The problem we have is that passing the focus around is really not a
great idea, because we just abuse the focus functionnality for our
needs, and it causes problems everywhere..

The only good approach is the one used by the completion popup (even if
it's ugly). The focus stays in the entry (so one can edit the text, move
the cursor, type, etc), and special key presses are intercepted and make
the treeview cursor move (like up/down, pageup/down, etc).

I assume somehow the generic model for deskbar will always be an entry
where you type things, and a treeview appearing somewhere where results
appear. In that case, it is right to make the entry a little special and
pass it the treeview that it controls. We can abstract away the popup
thing, but the very least we can do is to pass the treeview in the
constructor (or in a set_treeview()).

I'll see if i can come up with a reasonable implementation for that to
see if it's possible at all..

> 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).

Cool, i hope you'll get back the Teh Intarweb soon!

Raf