Re: [XaraXtreme-dev] Latest build test.

[Mart Raudsepp <leio@xxxxxxxxxxxx>]

On Sun, 2006-05-07 at 21:27 +0100, Alex Bligh wrote:
> Mart,
> 
> --On 07 May 2006 18:41 +0300 Mart Raudsepp <leio@xxxxxxxxxxxx> wrote:
> 
> >> All I did was convert them over, then add the tooltips to the bars
> >> themselves. The combo control not removing tooltips would seem to be
> >> (yet another) wxComboBox problem.
> >
> > Which should be fixed. Is this something in only wx2.6, or also in HEAD?
> 
> The tooltip bug? (no tooltip on the dropdown button). I have only
> seen it in 2.6 but I only ever link LX against 2.6. Should be trivial
> to replicate.

I'm mainly asking because HEAD uses the non-deprecated gtk combobox
control. GtkComboBox instead of GtkOptionMenu.

> > I must admit I haven't read over the long wxODComboBox wx-dev ml thread
> > yet.
> >
> > And nativeness?
> > Native GTK combo box can do whatever you want to do, it's about the wx
> > API not exposing it. Perhaps could work with wxODComboBox first,
> > assuming it has a sensible API for the needs you have, and then
> > implement it natively for GTK?
> 
> It seems to be the native combo which is causing all the problems.
> wxODComboBox only uses native controls on MSW, where the combo box
> appears not to be broken. Now the GTK1 stuff is out, it may be
> possible to fix some of the native GTK brokenness. The problems
> are (in no particular order):
> * Can't set height of control to be less tall than default
> * Can't set width of drop-down
> * Can't owner render drop-down
> * Can't control when a vertical scrollbar appears on the dropdown (i.e
>   make dropdown deeper by default)
> * Can't control when a horizontal scrollbar appears - the dropdown
>   should go wider than the the control where necessary if the user wants
>   this as horizontal scrollbars are unusable on combos)
> * Can't set icon for drop down (need to change it if the control is
>   made smaller on some themes).
> 
> It may be that you can fix some of the above, but migrating the lot
> to wxODComboBox seemed easier. But that was before you enlightened
> us about gtkparsercfile or whatever it's called (which I have now
> abstracted, and I now name each gtk control with the internal camelot
> resource name - not the label - which should allow us to customize
> on a per control basis - see wxXtra/platform.cpp and wxOil/camplatform.cpp,
> plus DialogManager::CreateRecursor in wxOil/dlgmgr.cpp)

I'll have to take a look at all of the above sometimes

> > Yeah, it should all be a wxBookCtrl. If you store the pointer as a
> > wxBookCtrl, it should be mostly about just changing "new wxNotebook" to
> > "new wxListbook".
> > In many cases I agree with this approach, especially in cases where you
> > can design different icons for them - means it isn't a dynamical one.
> 
> Yep. I need to give it icons though somehow, I presume. I can load
> them straight off the IDD_ resource ID.

The sample should show to do it. I do it in my pet project as well.

> >> That must be us because it's a GTK native file dialog as far as I
> >> know and return works elsewhere.
> >
> > Yeah, haven't had any bug reports for this. There are a few things lying
> > around for GTK native file dialog, should take a look soon. I don't
> > think any of those are very problematic, and probably don't affect Xara.
> 
> We are doing nothing funny with the save dialog, and everything funny
> with key and focus handling. I expect it is as simple as we ought not
> to be screwing with keypresses when there is a modal dialog up.
> 
> >> No idea. Unless we are handling the double-click in some peculiar
> >> way, tripple click should be natively handled by the GTK control so
> >> it should do whatever GTK does on a tripple click.
> >
> > wxGTK suppresses GDK triple-click events, because wx doesn't have a
> > triple-click event. I find this quite... bad, but alas. I'm not sure if
> > it suppresses it on native controls as well.
> 
> It suppresses them even if it's not going to handle them? That is,
> um, dumb!

What it does can be seen in src/gtk/window.cpp
gtk_window_button_press_callback

> LX itself (on the page) I think expects a tripple-click to look like
> a double-click and a click in short succession. That's what MSW
> used to send through IIRC. Perhaps we can get it to break tripple
> and quad clicks down rather than just discarding them.

I think wx should add triple click events and just say that not all
platforms support it.
It shouldn't be hard to do a select-all on controls when FOCUS_IN
happens, though


-- Mart