Qt-jambi-interest Archive, March 2007
congratulations, naming conventions, shadows on combos
Message 1 in thread
1. First of all, thank you for making a product that finally makes it
possible to write decent front-ends in Java.
2. In the final version, will getters/setters follow the Java naming
convention? It's a bit distracting to see getters w/o the get prefix.
Same for setters.
3. Under Windows XP Classic Theme, the combo drop down menu in Qt
applications has a shadow. Other applications have a solid frame without
a shadow. It's a minor flaw, but it's very noticeable. I don't remember
if the Windows XP theme has shadows.
Message 2 in thread
Vadim Berezniker wrote:
> 1. First of all, thank you for making a product that finally makes it
> possible to write decent front-ends in Java.
Hi Vadim,
and thank you ;-)
> 2. In the final version, will getters/setters follow the Java naming
> convention? It's a bit distracting to see getters w/o the get prefix.
> Same for setters.
Most likely not. Qt uses the x() / setX() pattern for all its properties
and we want to be consistent with the Qt API in this area.
> 3. Under Windows XP Classic Theme, the combo drop down menu in Qt
> applications has a shadow. Other applications have a solid frame without
> a shadow. It's a minor flaw, but it's very noticeable. I don't remember
> if the Windows XP theme has shadows.
Indeed... When drop shadows are enabled, it appears that windows does
not draw them for comboboxes. I'll spin this off as a bug to the Qt
style team. Windows XP has support for enabling / disabling shadows in
the display settings.
best regards,
Gunnar
Message 3 in thread
> > 2. In the final version, will getters/setters follow the Java naming
> > convention? It's a bit distracting to see getters w/o the get
prefix.
> > Same for setters.
>
> Most likely not. Qt uses the x() / setX() pattern for all its
properties
> and we want to be consistent with the Qt API in this area.
Understandable, but could you not just put in getX()/setX() methods
anyway? Lots of frameworks and tools expect classes to adhere to this
JavaBean-style idiom, not to mention the hordes of Java developers to
which x()/setX() will look extremely foreign.
Trent.
