[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