[Lazarus] Find dialog too tight for translations
Giuliano Colla
giuliano.colla at fastwebnet.it
Sun Oct 26 23:58:32 CET 2014
Il 25/10/2014 18:49, waldo kitty ha scritto:
> On 10/24/2014 5:34 PM, Giuliano Colla wrote:
>> Taking into account all suggestions, I came out with two possible
>> layouts:
>>
>> Option 1 = Buttons at the bottom of the form (like in my previous
>> version)
>>
>> Option 2 = Buttons at the right of the form (like in the original
>> version)
>
> i like them both... option 2 is like a lot of stuff that i work
> with... i have no preference between them at this time... maybe
> provide both so that implementers can choose which they prefer in
> their project?
>
It would appear that the majority is for Option 2. However, before
submitting a patch, I'd like to see if the proposal of a user selectable
layout is viable. Not only to satisfy also the minority, but also to
clean up the situation, which currently IMO isn't too much satisfactory.
The idea of a selectable configuration has triggered the following
considerations.
What happens now is that in lcl/forms you have two units, one for the
Find dialog and one for the Replace dialog, each one with its form. You
must use them to design your forms. Once you're happy with them, you
must copy the code into one of the files included by the Dialogs unit
which loads also the lfm files generated when compiling the other units.
IOW quite a complicate situation, not too clean.
I gather that this is made necessary to avoid a circular dependency: you
cannot include a unit which uses LCLBase into the package LCLBase itself.
A cleaner solution would be to build those dialogs in code, like the
other ones in the Dialogs unit, without loading an lfm file from stream.
Besides the advantage of providing a configurable layout, this solution
could be implemented with an ancestor class of a generic Find/replace
dialog, from which those two dialogs could be derived. This would
provide the extra bonus to give to users the option of building their
own custom dialogs, deriving them from the ancestor class, for special
usage. A find/replace dialog used in an editor of po files may need the
options of selecting MsgId/MsgStr, an application may need to
enable/disable a search based on regular expressions, etc.
I'd like to investigate if this path can be followed without too many
difficulties.
Any observations?
Giuliano
--
Giuliano Colla
Project planning question: when it's 90% done, are we halfway or not yet?
More information about the Lazarus
mailing list