On 25.04.2018 0:03, Graeme Geldenhuys via Lazarus wrote:
My other suggestion was to simply place a TActionList on each Package
windows. Then define all the actions with associated shortcuts. The
Captions of each TAction doesn't need to contain the & symbol for a
hotkey (though highly recommended)
On 25.04.2018 2:35, Anthony Walter via Lazarus wrote:
I'm not sure, but I think all TCanvas drawing operations on graphic
objects with a pf32bit pixel format don't work. Essentially that are
read only surfaces. Is this intended and a won't fix problem or is
there a chance someone is willing to
Hi,
I tried two items from Lazarus Edit menu: Select to Brace and Select Code
Block. Both seem do nothing. Are they broken? I didn't use them before so I
expexted they would do what their name say. I have Lazarus 1.9.0 r57693M FPC
3.1.1 x86_64-linux-qt.
Thanks
V.
--
__
I am going to file a bug for this, but wanted to check with other people
first to see if I'm overlooking something.
So the problem is you cannot draw properly to any canvas backed by alpha
channel.
For example, if you have 2 TPortableNetworkGraphic images with images that
contain alpha channels a
On 2018-04-24 21:20, Ondrej Pokorny via Lazarus wrote:
>> Unfortunately that's how the TToolBar works. No chance to change it.
>> We'd need a new toolbar component that would accept focus for the tool
>> buttons.
> There is one way to do it more simply: add &-hotkeys to the buttons.
> E.g. the he
On 24.04.2018 22:14, Ondrej Pokorny via Lazarus wrote:
On 24.04.2018 21:41, Graeme Geldenhuys via Lazarus wrote:
Currently I can't tab between toolbar buttons, can't trigger the "More"
dropdown.
Unfortunately that's how the TToolBar works. No chance to change it.
We'd need a new toolbar compo
On 24.04.2018 21:41, Graeme Geldenhuys via Lazarus wrote:
On 2018-04-24 19:36, Ondrej Pokorny via Lazarus wrote:
The "Source -> Enclose in IFDEF" dialog comes to mind.
I don't see a problem here. Can you be specific?
I've just retested with Lazarus Trunk, and indeed it is keyboard
friendly now
On 2018-04-24 19:36, Ondrej Pokorny via Lazarus wrote:
>> The "Source -> Enclose in IFDEF" dialog comes to mind.
>
> I don't see a problem here. Can you be specific?
I've just retested with Lazarus Trunk, and indeed it is keyboard
friendly now. It definitely wasn't so before. Not sure when it got
On 2018-04-24 19:57, Santiago A. via Lazarus wrote:
> * Test subjects consistently report that keyboarding is faster than
> mousing.
> * The stopwatch consistently proves mousing is faster than keyboarding.
>
> This contradiction between user-experience and reality apparently forms
> the b
@Graeme
The "Source -> Enclose in IFDEF" dialog comes
to mind. The Package windows too. Some of these I have tweaked locally
to suite my needs better
Pls, list issues [easy] with all IDE dialogs- i will try to fix em.
--
Regards,
Alexey
--
___
Lazar
On 2018-04-24 19:22, R0b0t1 wrote:
>> Back to Lazarus - there are some dialogs that totally annoying me
>> because they were not designed with keyboard users in mind.
>> ...snip...
>
> The things in the last paragraph especially are what I do not like. It
> may be that taking inspiration from eithe
El 23/04/2018 a las 17:53, Santiago A. via Lazarus escribió:
> Time ago I read that interviews to developers after tests show
> consistently that shortcuts are faster, and clock consistently shows
> that mouse is faster.
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
We’ve done a cool $50 mi
On 24.04.2018 19:28, Graeme Geldenhuys via Lazarus wrote:
Back to Lazarus - there are some dialogs that totally annoying me
because they were not designed with keyboard users in mind. ie: Wrong
default actions, or no default actions, wrong default focus item,
incorrect tab order etc.
I am quite
On Mon, Apr 23, 2018 at 10:53 AM, Santiago A. via Lazarus
wrote:
> These studies show that the most efficient is toolbar; second, keyboard
> shortcuts; third, second level menu option. With the objection that
> shortcuts needs a lot of practice to be better than menu.
>
How well did those studies
On 2018-04-23 16:53, Santiago A. via Lazarus wrote:
> These studies show that the most efficient is toolbar; second, keyboard
> shortcuts; third, second level menu option. With the objection that
> shortcuts needs a lot of practice to be better than menu.
Maybe for other programs, but for programm
fix for BorderStyle, dialog was resizable and preview rect is not
resizable (dont fit to big size)- looks bad.
--
Regards,
Alexey
Index: components/printers/unix/udlgpagesetup.lfm
===
--- components/printers/unix/udlgpagesetup.lfm
16 matches
Mail list logo
