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
