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

RE: [XaraXtreme-dev] Latest build test.

> > - The program still crashes when you close documents. This 
> crash has 
> > existed since day one of LX. Is anyone down to fix it. Sort 
> of makes 
> > it not useful in the real world.
> Can you duplicate this? I've /never/ seen it, and I open and 
> close docs all the time.

I'm not in front of a Linux machine right now, but I thought there as a
bug report in Bugzilla about this from me. From memory you do something
like load one document, load another and then move an object on the
second and close it -> Bang. (or was it on the first).

Hmm I can't find the bugzilla report which is concerning as I know this
has been detailed more than once.  Oh well I just found a machine and
tried. This is 100% repeatable and very easy to reproduce. Load the
first example design, the corvette, then click the new document icon and
draw a rectangle. Close this document. Bang. Perhaps doesn't happen on
debug builds, but does on retail binary.

> > - Ah I've just realised the missing status bar (or rather 
> non-working
> > one) is also a bit of a showstopper for the next stable release. No 
> > one working on it as far as I know.
> It should be reasonably trivial. I think someone volunteered 
> then we saw no code.

I don't think that's going to happen, so it's probably down to one of us
to do. Should be done soon I think as it's pretty important usability

> > - Tool tips are appearing in all sorts of random places. 
> Yes it's meant to be there for those dialogs which are 
> dockable that don't have title bars (e.g. bars) because you 
> can't tell what they are otherwise. I use it internally too 
> to get the correct title bar name when they are floating. It 
> is annoying for galleries (at least over the main control) so 
> I'll see if you can switch it on.

Er, you mean off? I see it on open and docked galleries with a title
bar, so that's not right.

> > - And similarly if you mouse over, say, the arrow of the line width 
> > combo box, a tooltip appear saying 'standard bar' and it 
> remains there 
> > on screen while you select and traverse the menu, sometimes 
> appearing 
> > over the drop-down menu, sometimes under.
> It should ONLY be there if there is no tool tip on the line 
> width combo box (which clearly should have a tooltip of it's 
> own). Bringing up the menu should remove the tooltip. If it 
> doesn't, that's a bug.

Nope, the arrow of the combo box has a tooltip of 'standard bar'. The
field has the correct tooltip saying line width or zoom. But clearly
that tooltip should apply to the whole control.

And yes for me 100% reproducible, if I move over the combo box arrow,
tooltip appears, not click the arrow so the menu appears, the tooltip
remains on screen now half covered by the menu. And it remains there.

And a new bug - if you do this in a new blank document you get an error
saying 'no objects are currently selected. Do you wish to make the 'line
width' attribute a Current Graphics Attribute'.  Fair enough you say,
but if I clear this alert (Cancel), it immediately appears again if I
move the mouse. 

> But I having the tooltip on the bar /outside/ the controls is 
> very useful otherwise there is no obvious indicator as to 
> which bar it is (if say you want to switch it off).

I agree, if it worked, it probably would be useful. Although I think the
correct name should be "Infobar" and not "info bar". I think that's the
term we've agreed on.

I've also noticed the tooltip for the 9-way origin buttons has changed
and is technically wrong. It say set rotation point, but in fact it's
the original for all transforms including scale. The original said 'set

> > 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. But I have 
> wxODComboBox in the code base (but not being used yet) so it 
> shouldn't be there for long!

Well that would be good.

> > - Arg - the two layer tabbed Options dialog has become a 
> weird scrolly tabbed dialog.
> Indeed. wx uses the standard GTK control which does that 
> (yuck). 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.

Completely agree, it is a better UI.

> I can almost certainly convert the 
> tabs over to one of these without redoing the UI in each tab 

Well if rows of tabbed dialogs is not easy, perhaps we should break our
rule an make a UI change. Inkscape have apparently just implemented this
style new options dialog, and it's very nice according to reports. So
perhaps we borrow some of their icons. Don't have a screen shot I'm
afraid. I should attach one.