Re: [XaraXtreme-dev] Latest build test.

[Mart Raudsepp <leio@xxxxxxxxxxxx>]

On Sun, 2006-05-07 at 12:11 +0100, Alex Bligh wrote:
> > Has anyone been messing with the tooltip area?
> 
> 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?
I must admit I haven't read over the long wxODComboBox wx-dev ml thread
yet.

> But I have wxODComboBox in the
> code base (but not being used yet) so it shouldn't be there for long!
> This will remove all the GTK combo box bizarreness.

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?

> > - Arg - the two layer tabbed Options dialog has become a weird scrolly
> > tabbed dialog. That is terrible, and actually not acceptable. Again I
> > can't believe this is the standard wx or GTK way - it's so inferior to
> > the standard multi-row tabbed dialogs of Windows (which themselves are
> > crap), that I can't believe people really think this is an acceptable
> > way of presenting large tabbed dialogs. How are you meant to see the
> > available options ? It's nuts.  Because our goal is to replicate the UI
> > as it, either we do just that (and remain compatible), or we take the
> > opportunity to do it properly so it's a better UI, in other words a new
> > Options dialog design.
> > (but it's great that it works and so much of it seem to work)
> 
> Indeed. wx uses the standard GTK control which does that (yuck).

It's reasonable under the GNOME HIG, that says "You shall not have more
than about 5 tabs", but in reality with dynamic tabs representing
documents it becomes a problem.
For this there is a GTK bug open, but I don't think there was a strong
agreement yet. Either a dropdown arrow for the rest of the tabs that
aren't visible, as in the gtk2.4+ toolbar API (seen often in evolution),
or multiline.
What is supported today in GTK, is setting a context menu for the tabs.
GTK app developers often utilize this to show all the tab names in it,
and select the tab in question on select.

> I could fix it (lots of wx work), but I'd rather convert it to use the
> standard book control thing (can't remember the name) with a scrolly
> list of icons down the left, rather than tabs at the top. But I wanted
> to ask first. I think these are a better interface when there are more
> than 3 or four tabs anyway. I can almost certainly convert the tabs
> over to one of these without redoing the UI in each tab (though that
> might be good to do in the end). Provided the control is in 2.6 and
> I don't have to backport it, this should be pretty trivial (the
> hardest bit will be designing an icon per tab).

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.

> > - I save a file, enter a filename and press return. Nothing happens. I
> > actually have to click the Save button. That's us isn't it, doing
> > something stupid. Please tell me that's us.
> 
> 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.

> > - In editable fields, such as the InfoBar, you can't triple click to
> > select the entire field. I thought this was another OS problem, but
> > actually I see I can triple click in fields such as the Save dialog
> > filename field, so that implies it's something we're doing, or not
> > doing, to enable this feature. (I think I had previously reported that
> > clicking in these fields should auto-select the entire field and I still
> > think this).
> 
> 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.

-- 
With regards,
Mart Raudsepp

Project manager of wxMUD      - http://wxmud.sourceforge.net/
Developer of wxWidgets        - http://www.wxwidgets.org/
GTK+ port maintainer of OMGUI - http://www.omgui.org/