[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Latest build test.

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


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.


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!

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.

Alex