subject:"Re\: \[lazarus\] Delphi incompatibilities in TForm"


Giuliano,

I fully agree with you and couldn't say it better myself.  This is our
company's feeling about commercial software as well.  The same thing
could be said for my previous two companies I worked for.  The clients
dictates what they like and we must supply - after all, they paid for
the software.  We always implement two or three different GUI styles
in a prototype. Show it to the client and 100% of the time they choose
the one that isn't based on standard Windows style guides (all my
previous projects were Windows only - the latest one isn't).  Simple
things like alternate colors in grid rows to button style tabsheets,
etc..

The OS theme should be used as a default to the LCL, but the developer
must ultimately be able to override those defaults via properties or
sub-classing components. And those changes must be able at design time
and runtime.

Regards,
 - Graeme -


On 4/17/07, Giuliano Colla [EMAIL PROTECTED] wrote:


 In this case the developer has the option to use an application specific
appname.gtkrc file to override the standard theme and use his own.


 This is hardly a solution.

 What real people in real world needs is to give the right appearence to
widgets, in order to create user friendly applications. This means
dynamically changing colors, image backgrounds, and whatever is needed to
convey the right information in the most intuitive way. For the same
reasons, buttons and other widgets are often of different size and shape,
and widget style and theme goe to hell.

 A default theme is a goot thing for beginners, just to provide them a
consistent starting point, but as they proceed and learn, they override the
theme more and more frequenly, until nothing is left.
 The sacred cow of Widget Style can be reasonable for default values, but
nothing more.

 Besides my company needs, which doesn't give a damn about themes and widget
style, of all the commercial Delphi application I've seen, and I've seen
quite a lot, there's none which sticked to any known widget style, but all
of them were using colors, shapes and bitmaps consistent with company style,
and application needs, which was neither Qt, nor Windows, nor, God forbid,
Gtk.

 Just my penny of wisdom, late in the night.

 Giuliano


_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


On 4/17/07, Felipe Monteiro de Carvalho
[EMAIL PROTECTED] wrote:

Mark, could you point us to how to fix this? (Which is something much
better to do rether then pointlessly arguing about this)

What exactly is theming support? How does one implement it? Are there
functions in Gtk to retrive the colors for the theme, and then you use
them and set the color for the app?

And how could one set the color of a form? I searched a lot, but the



I wonder if it wouldn't be done similar to the suggested ways of
changing the GtkLabel background color.  I did some Google'ing and for
a GtkLabel they seem to create a in-memory rc-style (something like
that). Apply the colors to the rc-style and apply the style to the
GtkLabel.

Take all this with a pinch of salt, as I have no idea how low level
Gtk works.  I only use the LCL. :-)



code is a bit hard to understand. There are several layers of
components on a TForm on gtk. There is a normal widget, then a
scrolling widget, then another widget to make the client area separate
from the menu, and then another thing...


Good question..



--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


Felipe Monteiro de Carvalho ha scritto:

Mark, could you point us to how to fix this? (Which is something much
better to do rether then pointlessly arguing about this)

What exactly is theming support? How does one implement it? Are there
functions in Gtk to retrive the colors for the theme, and then you use
them and set the color for the app?

And how could one set the color of a form? I searched a lot, but the
code is a bit hard to understand. There are several layers of
components on a TForm on gtk. There is a normal widget, then a
scrolling widget, then another widget to make the client area separate
from the menu, and then another thing...



I tried to debug, step by step, and one gets up to the point where a

TGtkWidgetSet.SetWidgetColor

is executed in gtkobject.inc, which finally calls a

gtk_widget_set_style(aWidget,windowStyle)

after setting some windowStyle fields.
The same procedure is used for other widgets, such as buttons, where it 
works.


Maybe the catch is in either setting windowStyle fields, or in calling 
the set_style method.


From Glade I understand that a GTK form has no background color in 
itself (just a transparent background, about Style consistency!) but 
only a bitmap, so maybe a form widget should be treated differently from 
other widgets. Either setting other fields of windowStyle, or using a 
different method if AWidget is a form.


If nobody is more knowledgeable, we may attempt the hard way, of trial 
and error, such as setting different windowStyle fields, or a different 
approach, tampering with form's canvas (as I currently do, but from the 
application).


Giuliano

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-17 Thread Lord Satan

On Tue, 17 Apr 2007 03:09:11 +0200
Giuliano Colla [EMAIL PROTECTED] wrote:

 Lord Satan ha scritto:On Mon, 16 Apr 2007 23:58:30 +0200
 Graeme Geldenhuys [EMAIL PROTECTED] wrote:
 
   Forcing all GTK applications to always use the theming colors is *not*
 always the developers desire.
 
 In this case the developer has the option to use an application specific 
 appname.gtkrc file to override the standard theme and use his own.
 
   
 This is hardly a solution.
 
 What real people in real world needs is to give the right appearence to 
 widgets, in order to create user friendly applications. This means 
 dynamically changing colors, image backgrounds, and whatever is needed to 
 convey the right information in the most intuitive way. For the same reasons, 
 buttons and other widgets are often of different size and shape, and widget 
 style and theme goe to hell.
 
Real people are indows users? And the real world is the commercial one or do 
you mean crappy shareware apps as they do the same?
I don't think it is very user friendly to override the users personal theme 
settings. The most intuitive way to convey information forces you to ignore the 
users theme? I think you have some problems with GUI design and how it should 
work.  
But I won't argue with you anymore just go ahead, fix the problem and sent a 
patch.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

Lord Satan ha scritto:

On Tue, 17 Apr 2007 03:09:11 +0200
Giuliano Colla [EMAIL PROTECTED] wrote:

Lord Satan ha scritto:On Mon, 16 Apr 2007 23:58:30 +0200
Graeme Geldenhuys [EMAIL PROTECTED] wrote:

Forcing all GTK applications to always use the theming colors is *not*
always the developers desire.

In this case the developer has the option to use an application specific appname.gtkrc file to override the standard theme and use his own.

This is hardly a solution.

What real people in real world needs is to give the right appearence to
widgets, in order to create user friendly applications. This means dynamically
changing colors, image backgrounds, and whatever is needed to convey the right
information in the most intuitive way. For the same reasons, buttons and other
widgets are often of different size and shape, and widget style and theme goe
to hell.

Real people are indows users? And the real world is the commercial one or do you mean crappy shareware apps as they do the same?
I don't think it is very user friendly to override the users personal theme settings. The most intuitive way to convey information forces you to ignore the users theme? I think you have some problems with GUI design and how it should work.
But I won't argue with you anymore just go ahead, fix the problem and sent a patch.

You're right. If a feature isn't there, we do our best trying to provide
it. Then it's up to developers to decide if they want override user
theme or not. However, just to clarify my point of view, I've got a
couple of examples.

To test Lazarus, I've developed a small app wich mimcs Midnight
Commander. It's something anybody might want to use from time to time,
it's general purpose, and it *must* follow user personal preferences.
Colors, fonts, etc. can't be anything else but what comes from personal
theme choice. If the user loves a pink form, let him have it.

But my applications, those I get my bread and butter from, are meant for
customers which just have their specific needs, which go far beyond what
a theme can do. That's the real word I was speaking about. Such as using
a touch screen, and having buttons the size of your fingers and not the
size of your mouse pointer. Or coping with unskilled operators, which
are just confused by a Windows like behavior, because they're not used
to it. Jumping from one field to the next is made by arrow-up and
arrow-down, because TAB could be acceptable, but with SHIFT-TAB they get
confused. All application specific things, which do not fit in any
theme. But which make up quite a lot of the total.

So OK, lets follow a theme when it's reasonable, let's give the designer
the choice of overriding it when necessary. Delphi designers, which are
far from stupid, went that way. It's a good way and it would be a pity
to drop it. Delphi compatibility, IMHO should mean picking up the best
of Delphi, dropping the bad things.

Giuliano

_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


On 4/17/07, Giuliano Colla [EMAIL PROTECTED] wrote:


Back to business. I've got exactly the same problem, but for me, with
GTK1, changing the TEdit background color works just fine. Doesn't it
work for you?



Hey, progress!!!  It didn't work 2 weeks ago.  :-)

It's still not 100% though.  At least now the TEdit is consistent with
other controls that have the same bug.
http://www.freepascal.org/mantis/view.php?id=7555

I can change the background to a select few colors, but can't set it
back to the default clWindow.  See attached screenshot. The top edit
changed color when I blanked the field, but as soon as I entered data,
it should have changed to clWindow, which it didn't.


--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'


editscreen.png
Description: PNG image

Re: [lazarus] Delphi incompatibilities in TForm


On 4/17/07, Giuliano Colla [EMAIL PROTECTED] wrote:


You're right. If a feature isn't there, we do our best trying to provide
it. Then it's up to developers to decide if they want override user
theme or not. However, just to clarify my point of view, I've got a
couple of examples.

[snip]



I'm so glad someone understands what I'm trying to say.  You've hit
the nail on the head. Software is meant to be flexible and to fulfil
the end-users needs. My end-users paid for their software and they
don't want (for whatever reason that might be) the standard look for
certain things. Be that Windows software or Linux software.
As far as I understand from the theming support under Linux and
Lazarus. Does that now mean I can change the look under Windows
(TForm.Color for example), but not allowed under Linux.  I thought
Linux was all about choice! No suddenly we may have no choice.


I can even give real world example other than software.  ;-)
If we as people had to follow the same 'theme' the following would happen:

 * We would all wear identical clothes.

 * We would have the same color car - God forbid the wife says she
wants a red car. The factory said it must be black.

 * We would all drink the same brand beer (Ar)
etc.


PS 'Lord Satan':
As per your rules that we may not override themes, how would you
envision I notify my users what is required fields in a data entry
screen at Form Show (see my previous thread for a longer explanation).
An then notify them what is invalid or missing data at Save.  No
popups are allowed! In Delphi and Kylix I change the background color
of a TEdit to clYellow for required fields and clRed for invalid or
missing data.  As soon as valid information has been entered the
TEdit's background color changes back to normal (the default theme
color - whatever that might be).

--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


On 4/17/07, Giuliano Colla [EMAIL PROTECTED] wrote:

 I can change the background to a select few colors, but can't set it
 back to the default clWindow.  See attached screenshot. The top edit
 changed color when I blanked the field, but as soon as I entered data,
 it should have changed to clWindow, which it didn't.

This is true for all the controls I've tested.


Oops!  :-)




Cheer up, the road is long and full of sharp stones, but we'll make it!



:-) I'm sure we will.  Thanks for the work-around hints. I'll give them a try.



--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


Graeme Geldenhuys ha scritto:

On 4/17/07, Giuliano Colla [EMAIL PROTECTED] wrote:


Back to business. I've got exactly the same problem, but for me, with
GTK1, changing the TEdit background color works just fine. Doesn't it
work for you?



Hey, progress!!!  It didn't work 2 weeks ago.  :-)

It's still not 100% though.  At least now the TEdit is consistent with
other controls that have the same bug.
http://www.freepascal.org/mantis/view.php?id=7555

I can change the background to a select few colors, but can't set it
back to the default clWindow.  See attached screenshot. The top edit
changed color when I blanked the field, but as soon as I entered data,
it should have changed to clWindow, which it didn't.


This is true for all the controls I've tested.

My workaround: get the Hex value for the default color, and use it 
instead. In place of clBtnFace I use $E0E0E0, in my environment.

But if you must check the property later, you must set the color twice:

Widget.color := $E0E0E0; // Changes the color
Widget.Color := clBtnFace; // doesn't change anything but sets the 
property consistently with the color shown.


Cheer up, the road is long and full of sharp stones, but we'll make it!

Giuliano

P.S. I tried to set all conceivable fields of WindowsStyle to the 
desired color, but the result is always the same. The only workaround 
available is:
1) Form1.Color := clWatever; // this sets the form property which is 
seen by ParentColor of children widgets
2) Application.ProcessMessages; (otherwise the change is deferred, and 
the form goes back to the original color)

3) Form1.Canvas.Color := clWatever;
4) Form1.Canvas.FillRect(0,0,width,height);



Giuliano

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


Graeme Geldenhuys ha scritto:
[...]

PS 'Lord Satan':
As per your rules that we may not override themes, how would you
envision I notify my users what is required fields in a data entry
screen at Form Show (see my previous thread for a longer explanation).
An then notify them what is invalid or missing data at Save.  No
popups are allowed! In Delphi and Kylix I change the background color
of a TEdit to clYellow for required fields and clRed for invalid or
missing data.  As soon as valid information has been entered the
TEdit's background color changes back to normal (the default theme
color - whatever that might be).



Back to business. I've got exactly the same problem, but for me, with 
GTK1, changing the TEdit background color works just fine. Doesn't it 
work for you?


Giuliano

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-17 Thread Micha Nelissen

Graeme Geldenhuys wrote:
 Well again, our porting of the Delphi/Kylix application took a turn
 for the worse.  I can send a few screenshots to show what it looks
 like under Linux (not even close to what it should look like).  Under
 Windows it seems to be okay (for the most part).

Putting some screenshots in the wiki for a group of related issues may
be helpful: it shows a more concrete goal is reached than just simply
implement/fix a couple of random bug reports.

 Ah, enough of my ramblings  If anybody read this far, I'm impressed.
 :-)

It would be unethical to ignore you ;-).

Micha

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-17 Thread Lee Jenkins


Flávio Etrusco wrote:

2) Delphi Form has a Bitmap property which allows to set a background
image on the form, while Lazarus does not.



What version is it?
I vaguely remember seeing this on a very recent version of Delphi
(probably Turbo Delphi Explorer), but in Delphi7 there isn't any such
property...



Nor is there a property like that in D6.  I've always had to use TImage 
and stretch it across the form the few times I needed this functionality.


--

Warm Regards,

Lee



_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-16 Thread Felipe Monteiro de Carvalho


On 4/16/07, Giuliano Colla [EMAIL PROTECTED] wrote:

1) TForm.Color property sicks stubbornly to clBtnFace, whatever you do.


TForm.Color is not implemented on Gtk or gtk2 interfaces. I once tryed
to implement it, but it´s quite a huge mess, and I couldn´t make it
work.

TForm.Color works at least on win32 and qt. I never tested carbon to
see if it works there too.


2) Delphi Form has a Bitmap property which allows to set a background
image on the form, while Lazarus does not.


Not sure if we really need or want that. IMHO it´s better to use the
canvas to draw the bitmap if you want one.

--
Felipe Monteiro de Carvalho

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-16 Thread Felipe Monteiro de Carvalho


On 4/16/07, Alexsander Rosa [EMAIL PROTECTED] wrote:

IIRC, it's because the design choice was to let the Window Manager
choose the color.


I don´t think so. The default colors (like clBtnFace) are already
reserved for the Window Manager. Setting to clGreen for example should
always make it green.

--
Felipe Monteiro de Carvalho

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


On 4/16/07, Alexsander Rosa [EMAIL PROTECTED] wrote:

IIRC, it's because the design choice was to let the Window Manager
choose the color.


That would be a very 'bad design choice' then.  Sure, get the default
color from the Window Manager, but always allow the user to override
those if needed.

Our company stumbled across this bug a few months back, and also tried
to implement a fix, but couldn't figure it out.  The applications was
intended for a very specific audience and we needed a very graphical
look. We had to change background colors to merge with our TImage's
acting as buttons, etc...  In the end we move that application to a
web based application, so we could use HTML and CSS to get the look we
required.   Yeah, a lot of work to get around one bug, but the project
had to get done.  :-)




--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


On 4/16/07, Giuliano Colla [EMAIL PROTECTED] wrote:


1) TForm.Color property sicks stubbornly to clBtnFace, whatever you do.
Setting a different Color triggers a repaint, but the form is painted
with the default color. What is weird is that if you put a component
such as a Panel on the form and set its ParentColor true, then the
component is painted on the Form.Color you set, while the form below
doesn't change. See attached images. Panel1.Parent Color is set to true,
and an OnClick event sets Form1.Color to clLime.


This is a Bug under GTK1 and GTK2 only. Works fine under Win32.  I've
already reported it a few months back.


--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-16 Thread Flávio Etrusco


2) Delphi Form has a Bitmap property which allows to set a background
image on the form, while Lazarus does not.



What version is it?
I vaguely remember seeing this on a very recent version of Delphi
(probably Turbo Delphi Explorer), but in Delphi7 there isn't any such
property...

Cheers,
Flávio

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-16 Thread Marc Weustink

Graeme Geldenhuys wrote:
 On 4/16/07, Alexsander Rosa [EMAIL PROTECTED] wrote:
 IIRC, it's because the design choice was to let the Window Manager
 choose the color.
 
 That would be a very 'bad design choice' then.  Sure, get the default
 color from the Window Manager, but always allow the user to override
 those if needed.

That it doesn't work for you doesn't mean that it is a bad choice. It
was choosen this way, since setting the color would destroy normal
theming, so the bitmap background of forms would become invisible.

Marc

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-16 Thread Marc Weustink

Graeme Geldenhuys wrote:
 On 4/16/07, Marc Weustink [EMAIL PROTECTED] wrote:

 That it doesn't work for you doesn't mean that it is a bad choice. It
 was choosen this way, since setting the color would destroy normal
 theming, so the bitmap background of forms would become invisible.

 
 Then why give use the choice of a Color property on a TForm?  Why
 allow TPanel's Color to work and a few others...  It's inconsistent
 having some components Color property to work and others not.  Also I
 thought LCL is trying to be compatible with Delphi's VCL, which does
 allow the user to override the default Color.

Yes, that is why there is a color property, and until full theming
support is implemented, this behaviour will stay this way.

 Forcing all GTK applications to always use the theming colors is *not*
 always the developers desire.  

Forcing ppl to not use their theme either!

 Think in terms of fullscreen
 applications like Kiosk, etc.  A simple example of an application than
 shouldn't give a toss about the colors used by the window manager.

And all other kinsd of apps ?

 Instead the GUI of Kiosk apps are much more graphical.  Images for
 buttons, colorful backgrounds ,etc..
 
 Sorry, a bad design choice!

It is not a design choice, but more a choice of importance. All things
need to be implemented one by one and at that time the ability to keep
the form background was choosen above setting the backcolor. Since for
setting the back color you can have workarounds, for not showing the
theme background not.

Marc

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm

2007-04-16 Thread Lord Satan

On Mon, 16 Apr 2007 23:58:30 +0200
Graeme Geldenhuys [EMAIL PROTECTED] wrote:

 Forcing all GTK applications to always use the theming colors is *not*
 always the developers desire.

In this case the developer has the option to use an application specific 
appname.gtkrc file to override the standard theme and use his own.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm


On 4/17/07, Marc Weustink [EMAIL PROTECTED] wrote:


 Forcing all GTK applications to always use the theming colors is *not*
 always the developers desire.

Forcing ppl to not use their theme either!


Our issue came into play when we tested under both Linux and Windows.
We moved away from Delphi  Kylix to Lazarus with the hopes that we
can write our application under one platform, recompile under another
and both would look or work the same (as advertised).  Well, big
surprise when we ran the application developed under Windows (which
looked almost like we wanted) on a Linux system (which looked nothing
like we wanted).

Yes I know Lazarus is open source and yes I do contribute where I can.
:-)  And if I can't contribute myself, I'm willing to pay someone for
it. See the bounties wiki page.

And no this isn't just a issue with fullscreen style applications. The
following will probably have the same excuse as the TForm.Color issue.
In our non-fullscreen / normal desktop GUI application we have loads
of data entry screens. The users are required to fill in certain
fields. To indicate these required fields our business objects notify
the edit form about missing data and those associated fields (TEdit's,
TComboBox's, TSpinEdit's, etc) background color changes to clYellow.

Well again, our porting of the Delphi/Kylix application took a turn
for the worse.  I can send a few screenshots to show what it looks
like under Linux (not even close to what it should look like).  Under
Windows it seems to be okay (for the most part).

Now as per the TForm.Color design decision, I'm not allowed to change
the background color of widgets either, as that might interfere with
the windows managers theme, which again I don't give a toss about.

I can understand you guys want to adhere to the window managers
colors, etc.  So why not use those as defaults and if the developers
wants to override the color or font, etc let them, it's their
application.

Lazarus is now forcing us to come up with a complete new design for
notifying users about required or incorrect fields.  Our customers are
used to components changing colors and like it, as it make it very
clear what is required (they hate popup dialogs). Those customers will
now have to get used to something completely different in the next
release.
Oh by the way, users don't like change!



And all other kinsd of apps ?


We have desktop and fullscreen style applications.  Sometimes your
applications need to fit with the look or style the client likes, even
if that means it must look different to the window manager theme or
the GUI style guidelines of the OS.  Having the same application in a
cross platform environment look the same is important to them. At
least the most basic thing like color would be a start.

Don't get me wrong, our company likes Lazarus.
I'm just trying to highlight things that would be required for Lazarus
to be a viable alternative to Delphi.  No matter how small the issue
might seem, I think it is important I mention it - it's all in the
details.

I don't know how many other developers use Lazarus in a commercial
environment.  We design commercial software and we took a big chance
in switching to Lazarus.  I just think if more commercial developers
would think of Lazarus as a *viable* alternative to Delphi, Lazarus
will benefit from it.  Firstly, by getting more developers that will
submit patches, even to all those little details that got lost over
time. We already have and will continue to do so.  Also, if Lazarus
works for them, they are sure to tell others.  What company wouldn't
want to save money on development tools and licensing.  The Lazarus
user base will grow and out of that could come corporate sponsors and
we all know that's a good thing for open source projects.


Ah, enough of my ramblings  If anybody read this far, I'm impressed. :-)


--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Delphi incompatibilities in TForm