Giuliano Colla wrote:
Vincent Snijders ha scritto:
Giuliano Colla schreef:
Vincent Snijders ha scritto:
Graeme Geldenhuys schreef:
On 29/01/2008, Vincent Snijders <[EMAIL PROTECTED]> wrote:
You don't need ifdefs. You need to fix the differences.
Fix the gtk1 interface to scroll the memo.
Fix the gtk1 interface to remove the scrollbars, when the memo is
cleared
Fix gtk1 and gtk2 interface to disable childforms, if the main
form is enabled.
That is why there different widgetset backends too, not just to
create different
widgets, but also to make them behave consistent.
But how do you know if that's not maybe the native behaviour of the
underlying widgetset? I think this is what Giuliano was trying to say
or assumed.
Don't assume, research.
Not convinced,
GTK1 implementation of TMemo InsertText:
if NewTextLength - CutLength > 0 then begin
gtk_editable_insert_text(PGtkEditable(widget), char,
NewTextLength - CutLength, Position);
end;
g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text');
GTK2 implementation of Tmemo InsertText:
if NewTextLength - CutLength > 0 then begin
gtk_text_buffer_insert(TextBuffer, StartIter, TheText,
NewTextLength - CutLength);
end;
g_signal_stop_emission_by_name(PGtkObject(Textbuffer),
'insert-text');
GTK2 scrolls in order to show the text just inserted, GTK1 doesn't.
Convinced now?
Convinced, that you did some research: yes.
Convinced, that you did enough research: no.
Convinced, that scrolling the text after inserting text is agains the
native behaviour of the native widgetset: no, not at all.
IMO, the LCL should give the application users a native look and feel
using the native components as much as possible. At this moment, we
are failing in this respect with our current implementation of the
Treeview and the Toolbar, for example, since they are drawn by the LCL
and not by the widget set. This will probably change in the future,
keeping the current Treeview as TLCLTreeView or something like that.
The LCL should give the application developer a consistent (VCL
compatible) interface to accomplish that.
In this case when you append or insert text the application developer
expects that gtk1 and gtk2 (and all widget set) do the same thing:
either scroll to end or leave the cursor on the current position. I
don't think that this scrolling (or not scrolling) can be considered
intrisically part of a widget set.
Suppose we decide that a widget should scroll when adding line to a
LCL TMemo should scroll that line into view, then all widgetset should
do that. The gtk1 implementation should add extra code to accomplish
that.
Suppose we decide that a widget should not scroll when adding line to
a LCL TMemo should scroll that line into view, then all widgetset
should not do that. The gtk2 implementation should record the current
position and add extra code to accomplish to keep the cursor on the
current position.
I would sugest to fix the gtk1 implementation.
I hope this is clear now, if not, feel free to ask for clarification.
What you say is clear, and I do agree with you. LCL should provide
consistent behavior across widgetsets. Maybe I can disagree on what's
the best way (i.e. minimum work-best result) to achieve this result, but
that's another matter, and it's up to you, after all. I can just provide
my point of view as a contribute to the discussion.
But when I see other developers say exactly the opposite, i.e. that LCL
should provide "native" behavior, and maintain that some properties
shouldn't be implemented in some widgesets because they're not natively
available, then I get confused.
Native widgets <> native behaviour. The LCL adds functionality to native
widgets so a LCL user wil benefit from that and will het the same
behaviour. (also the VCL added some different behaviour to win32 widgets)
On case by case base it is decided if a certain behaviour is compatible
with delphi, is better than delphi or is behaving like most widgetsets.
For scrolling after a line is added, I don't know. Personally I hate it
when a memo gets updated and I want to read the contents the same time.
Marc
Giuliano
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
