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

Re: [XaraXtreme-dev] Latest build test.

Charles,

--On 07 May 2006 11:43 +0100 Charles Moir <CharlesM@xxxxxxxx> wrote:


At last the Freehand tool now works properly - fantastic. This is now
becoming a usable program.

Er, except quite a few things broken in the latest builds. I hate
Bugzilla with a vengeance, so I'm just listing them here.


Well those of us fixing things appreciate the bugs being in there,
but:


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


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


- Tool tips are appearing in all sorts of random places. e.g. when I'm
over the layer gallery, below this appear the 'layer gallery' tooltip
that stays there all the time while the mouse point is over the gallery.
(This tooltip it's not even needed and shouldn't exists even. The
gallery has a huge title bar telling you what it is),


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.


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


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!
This will remove all the GTK combo box bizarreness.


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


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


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


- The Zoom tool magnifier mouse cursor has changed. I'm sure it was
correct before. now it's missing the cross-hairs in the center of the
icon. That's a bit weird.
- Drag bitmap onto page background, hold Ctrl, to make this page
background, and the pointer remains in a strange mode with a 'no entry'
symbol attached.  Actually I've seen this when dragging things in
galleries.


Yes I've seen that too. I /think/ it's a dragmanager/cursor capture problem.

Alex