I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own. (I would've expected something to complain about there being two CustChoice::handle()s in that case...) Would it be considered incorrect in any way if fltkui.cc's CustChoice and CustInput2 were put inside dw::fltk::ui?
On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote:
I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own.
Funny how this also annoys me, while thinking it was one of your patches that changed the behaviour! ;-) Of course I'm not sure, and will review the issue, but *feel* happy about not being alone in longing for the old bahaviour. -- Cheers Jorge.-
Jorge wrote:
On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote:
I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own.
Funny how this also annoys me, while thinking it was one of your patches that changed the behaviour! ;-)
Of course I'm not sure, and will review the issue, but *feel* happy about not being alone in longing for the old bahaviour.
Perhaps we could have one CustChoice that everything uses, although I don't know where we'd put it.
On Sat, Jan 26, 2013 at 04:55:53PM +0000, corvid wrote:
Jorge wrote:
On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote:
I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own.
Funny how this also annoys me, while thinking it was one of your patches that changed the behaviour! ;-)
Of course I'm not sure, and will review the issue, but *feel* happy about not being alone in longing for the old bahaviour.
Perhaps we could have one CustChoice that everything uses, although I don't know where we'd put it.
Yes, I'm also looking on that... Well, at least I have code to "fix" the dialog issue and also let FORM options also work as the search dialog. I'm yet to find out why the compiler/linker *seems* to be picking the wrong CustomChoice class. I focused on fixing the practical problem first. Patch soon. -- Cheers Jorge.-
On Sat, Jan 26, 2013 at 04:55:53PM +0000, corvid wrote:
Jorge wrote:
On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote:
I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own.
Funny how this also annoys me, while thinking it was one of your patches that changed the behaviour! ;-)
Of course I'm not sure, and will review the issue, but *feel* happy about not being alone in longing for the old bahaviour.
Perhaps we could have one CustChoice that everything uses, although I don't know where we'd put it.
OK, simple patch committed (avoiding compiler/linker confusion) Currently dw is mainly self contained so there's no easy place to put a custom class used by both. They're a bit different anyway, so it doesn't hurt. I also made FORM option menus activable with down key. I'm not sure this is a good thing though. @corvid: as a keyboard user, please check whether this improves things or not. It's quite easy to reverse if not (old behaviour: scroll page. new: activate menu if option is focused). -- Cheers Jorge.-
Jorge wrote:
I also made FORM option menus activable with down key. I'm not sure this is a good thing though.
@corvid: as a keyboard user, please check whether this improves things or not. It's quite easy to reverse if not (old behaviour: scroll page. new: activate menu if option is focused).
I'm not sure either.
participants (2)
-
corvid＠lavabit.com -
jcid＠dillo.org