Hello, Chris!
I was testing the hotkeys in bzr 6494.
Duplicate hotkeys still don't get recognized when there is
the Alt-key envolved.
I am able to assign i.e. Alt-W or Ctrl-Alt-E to several
commands at the same time.
Ctrl-Tab ist still assigned as Ctrl-I (well, it's not
nice but not a
Eh, as well...
I forgot that I have the official 4.0.1-stable installed on Arch Linux,
which also has the "Alt-* duplicate hotkeys are possible" bug.
So, I bet it's an ooold thing.
Regards,
Clemens
On 2016-01-18 01:01, Chris Pavlina wrote:
> Eh, don't worry about bisecting or anything, I can
Thanks.
Don't remember if I said this, but Ctrl-Tab being picked up as Ctrl-I is
an old issue - I do actually plan to fix this, though.
As for duplicate hotkeys not being recognized - do you still have an old
build kicking around to test for me if this is a regression or not? I
*think* it
Eh, don't worry about bisecting or anything, I can take care of this.
The hotkey stuff hasn't been touched in quite a long time - I'll just
grab a build from before I started, see if it still does it, and if so
just go right into the code and fix it.. if it's an old bug it'll be an
ld one,
Looks like the text overflow was actually a wx bug - it insisted on
computing the size of the wxStaticText based on the smaller default font
instead of the larger one I had set.
Easily solved by just not setting a larger font. Still looks fine.
Patch attached.
On Mon, Jan 11, 2016 at
It seems like this may be one of those issues where we have to
compromise on the design. Once you figure out the hotkey entry dialog
text overflow issues I'm fine with committing the changes. Everything
else seems to work as expected.
On 1/11/2016 3:00 PM, Chris Pavlina wrote:
> Well, yes, that
Le 11/01/2016 17:41, Chris Pavlina a écrit :
> I like having the hotkeys under 'controls' - first, they _are_ controls,
> and second, the controls page is really sparse otherwise, it looks a bit
> silly without something in there. ;) Obviously it could be moved, I'm
> not particularly attached
I like having the hotkeys under 'controls' - first, they _are_ controls,
and second, the controls page is really sparse otherwise, it looks a bit
silly without something in there. ;) Obviously it could be moved, I'm
not particularly attached to it one way or the other. I'd rather get
this
Le 11/01/2016 16:28, Chris Pavlina a écrit :
> An updated version of the patch is attached - doesn't apply cleanly
> anymore after 6442.
>
Thanks, Chris.
Looks good for me, but I am thinking the hotkeys editor should be shown
in a notebook new page specific to hotkeys, not the existing control
An updated version of the patch is attached - doesn't apply cleanly
anymore after 6442.
On Sun, Jan 10, 2016 at 04:28:24PM -0500, Wayne Stambaugh wrote:
> Sorry Chris. I've been busy and just didn't get to it yet. I'll try to
> take a look at it today or tomorrow.
>
> On 1/10/2016 4:13 PM,
On 1/11/2016 2:16 PM, Chris Pavlina wrote:
> Had to change the capture method for both reasons. The old wxListCtrl
> (IIRC) was the _only_ widget that captured them correctly.
Maybe that's why the person who design the original hotkey dialog end up
using wxListCtrl. It's certainly something to
Had to change the capture method for both reasons. The old wxListCtrl
(IIRC) was the _only_ widget that captured them correctly.
I'm not completely a fan of the dialog either, but it's not all _that_
bad, and we're not the only ones doing it that way. At very least the
XFCE settings dialog
Chris,
I just finished testing this and I'm not sure about using a dialog to
capture the hotkey press. Did you have to do this to overcome using the
tabbed dialog or was it due to changing the control to a tree control?
If it's the tabbed dialog design, it might be worth leaving the hotkey
>Maybe that's why the person who design the original hotkey dialog end up
>using wxListCtrl. It's certainly something to consider. I know it
>doesn't layout as nice as the tree control.
Yes I already bothered him on IRC on why I did it as a wxListCtrl
which replaced the original hotkey dialog
Well, yes, that would be why it was selected. I don't like the idea of
limiting ourselves so much (must be wxListCtrl, must be an otherwise
mostly empty dialog) just because of a quirk of the way wx processes
events, though, and IMO the dialog method isn't all that bad. Nice and
clean with the
Just to clarify - Wayne, are you still having a look at this, or were
you just expecting me to merge my own patch when it's done? I think it's
ready to go in.
On Fri, Jan 08, 2016 at 01:16:52PM -0500, Chris Pavlina wrote:
> Hi,
>
> Jesus, here be dragons. Finally got the hotkeys stuff working
Sorry Chris. I've been busy and just didn't get to it yet. I'll try to
take a look at it today or tomorrow.
On 1/10/2016 4:13 PM, Chris Pavlina wrote:
> Just to clarify - Wayne, are you still having a look at this, or were
> you just expecting me to merge my own patch when it's done? I think
Hi,
Jesus, here be dragons. Finally got the hotkeys stuff working properly
on all platforms - this has been tested on Linux, Win10, and OSX. Thanks
to JP for a push in the right direction (and even that required more
work!).
Quick summary of the problems:
- On Windows, there is a
On Fri, Jan 08, 2016 at 01:16:52PM -0500, Chris Pavlina wrote:
> Hi,
>
> Jesus, here be dragons. Finally got the hotkeys stuff working properly
> on all platforms - this has been tested on Linux, Win10, and OSX. Thanks
> to JP for a push in the right direction (and even that required more
>
This is worse than web development. And that's saying something :)
On Fri, Jan 8, 2016 at 11:16 AM, Chris Pavlina
wrote:
> Hi,
>
> Jesus, here be dragons. Finally got the hotkeys stuff working properly
> on all platforms - this has been tested on Linux, Win10, and OSX.
On Fri, Jan 08, 2016 at 09:34:42PM +0100, Marco Ciampa wrote:
> On Fri, Jan 08, 2016 at 01:16:52PM -0500, Chris Pavlina wrote:
> > Hi,
> >
> > Jesus, here be dragons. Finally got the hotkeys stuff working properly
> > on all platforms - this has been tested on Linux, Win10, and OSX. Thanks
> >
21 matches
Mail list logo