Probs trying to make a "nighttime" config environment

Jaymer

so, using Window control panel to alter colors & appearance, one can ALMOST make a satisfactory environment for countless hours spent in the Configurator.

I can't believe how much my eyes "stopped screaming" when I changed to a dark theme in Notepad+
Made all the difference in the world... instantly. Switch back to normal and felt eye pain/strain that I didn't know was there.

So, there are TWO MAIN ISSUES in the Eclipse Config tool that I see hindering occular bliss

1) We need control over the colors in the LEFT ELEMENT TREE
The fact that Vlad has picked the green/blue/pink colors and hardcoded them in, keeps you from changing the overall Windows background to a dark color - because you cannot see the GREEN & BLUE elements on a dark bg.

2) See this example using the windows "high contrast white" color scheme.
NOTE: This shows the issue on white, even though this topic is about a "night" screen. With BLACK/DK GRAY
backgrounds, its too hard to see for purposes of this example
Screen Shot 2018-12-15 at 4.41.32 PM.png

You can see the SELECTED TEXT settings for White Text on Purple. This works fine when selecting a Form or expanding sections on Forms. But as I said above, the problem is with the ELEMENT TREE on the left.
If Vlad would allow the Element Item to be selected the same as the Form Name is selected, then it would be fine. But "I think" because he specifically colors the ELEMENT TREE, it doesn't conform to normal UI rules. See this:
Screen Shot 2018-12-15 at 9.14.14 PM.png
This is un-usable, yet its the same kind of windows tree control that DOES WORK when showing Forms & Form Sections (see 1st pic)

3) The other area that becomes unusable is:
Screen Shot 2018-12-15 at 4.43.23 PM.png

Jaymer

So, we need, even if the colors for these 6-10 extras are put into one of the .config files, better control to save our eyes.
A "night" theme was listed as an 8.2 wishlist item, but we can basically do it now if we get support to spend an hour or 2 and read those color constants from a config file instead of being hardcoded inside.

BenHayat

I really hope support will give us a "Dark" theme, something like this color combo.

Jaymer

well, I have felt more coloring like that would be really useful in the Rule Editor.

Personally, I think ALL Aware apps should be written using, what I think was Mark or Heidi's, PREFIX rules for naming References.
BUT, people don't do that.
IF, Owner field, and Owned By field, and Peer fields (etc etc), Shortcuts had specific [user-definable] colors, then in a rule editor one might see:

IF Customer.Rep IS UNDEFINED THEN 1=1 (reference, should be ps_Rep)
IF Customer.StateName = 'Florida' THEN REPORT ERROR Christmas user gathering at Bruce's house (shortcut, should be sc_StateName)

instead of
IF Customer.Rep IS UNDEFINED THEN 1=1
IF Customer.StateName = 'Florida' THEN REPORT ERROR Christmas user gathering at Bruce's house

See, currently, when someone is NOT adding prefixes to fields, then the 1st example lines above DO NOT INFORM YOU that the field is NOT a real, local field.
So, adding the prefix helps, but when you go to read someone else's code WITHOUT prefixes, it really slows you down.
Using the colors, you can easily see a Reference and a Shortcut without even thinking about it.

BenHayat

Jaymer wrote
well, I have felt more coloring like that would be really useful in the Rule Editor.

Personally, I think ALL Aware apps should be written using, what I think was Mark or Heidi's, PREFIX rules for naming References.
BUT, people don't do that.
IF, Owner field, and Owned By field, and Peer fields (etc etc), Shortcuts had specific [user-definable] colors, then in a rule editor one might see:

IF Customer.Rep IS UNDEFINED THEN 1=1 (reference, should be ps_Rep)
IF Customer.StateName = 'Florida' THEN REPORT ERROR Christmas user gathering at Bruce's house (shortcut, should be sc_StateName)

instead of
IF Customer.Rep IS UNDEFINED THEN 1=1
IF Customer.StateName = 'Florida' THEN REPORT ERROR Christmas user gathering at Bruce's house

See, currently, when someone is NOT adding prefixes to fields, then the 1st example lines above DO NOT INFORM YOU that the field is NOT a real, local field.
So, adding the prefix helps, but when you go to read someone else's code WITHOUT prefixes, it really slows you down.
Using the colors, you can easily see a Reference and a Shortcut without even thinking about it.

Great Idea. I had used editors in the 80's that were better 😃

ACDC

Jaymer, when you listed the items that did not make it into 8.2m Vlad commented

Other items in the list were deemed "too hard" (for this version at least)

I somehow don't believe that. I think the Dark Theme was just not a priority.

Support please will you consider this feature 🙁 I wear contact lenses and the DARK THEME will be a godsend.

ACDC

Personally, I think ALL Aware apps should be written using, what I think was Mark or Heidi's, PREFIX rules for naming References.
BUT, people don't do that.

Way back in 2007 when I was learning about the rule language and naming of objects, I was advised by someone (i think it may have been Vlad) to keep Object names singular and to ensure that the Object name was meaningful. So when reading rules they made English sense.

When you start adding prefixes as per the suggestion and advice given in this forum, it starts to garble the rule up into some kind of code which becomes unreadable to those that are not familiar with the practice. IMHO I think its a BAD practice. Whenever I read some example rules put forward in the forum that use this naming convention, my brain gets confused and i just move on 😮 🙁

The concept of using colours to distinguish the relationship is an excellent idea, please can we get this feature, hopefully it will restore some sanity 🙂 and provide a more productive environment

Jaymer

ACDC wrote
The concept of using colours to distinguish the relationship is an excellent idea, please can we get this feature, hopefully it will restore some sanity 🙂 and provide a more productive environment

I had this idea several years ago when I first started using Aware.
Since I was NOT using Prefixes, and coming from Magic, I started making Semantic errors - not remembering/realizing an Attribute was a Object and treated it like a Number.

ex. FIND Invoices where CustomerID = Customer (should have been Customer.ID)

And I realized then that Coloring these different object types in the Rule Editor would solve all the confusion.
Its gotten harder as I find myself getting into projects where someone else has written code (maybe poorly, maybe not)... but just seeing the word Customer gives you no clue as to what kind of object it is.

hpl123

1+ for dark theme

PointsWell

Screen Shot 2018-12-17 at 19.00.18.png

Before that and probably easier to do - the application icon needs a background as it doesn't show properly in night time mode.

ACDC

Before that and probably easier to do - the application icon needs a background as it doesn't show properly in night time mode.

In dark mode, images would become grayscale monochrome

BobK

Jaymer wrote
what I think was Mark or Heidi's, PREFIX rules for naming References.

I would like to refresh my old memory and need help finding those rules.

Jaymer

ob owned by
ps / pm peer single & mult
os / om own single & mult
sc shortcut

om_transactions
ob_tenant
ps_salesrep
sc_RepName

BobK

Thank you

customaware

The PreFixes have definitely helped me enormously.
Here are some a few things that may not be so obvious before you start using them and while Colours would be great....still would not help with these.

Firstly, the BO Attribute List.... Notice how all the References and Shortcuts are grouped together. Makes it much easier to not only FIND what you are looking for but also... understand what type of Reference it is just at a glance.

Secondly....

Imagine the following BO structure.....

Without using PreFixes your BO Attribute lists would looking something like this....

TENANT
TenantName
DateCreated
Status
Countries

COUNTY
Country
OfficeAddress
Tenant
Entities

ENTITY
EntityCode
EntityDescription
Country
Departments

DEPARTMENT
DepartmentCode
DepartmentDescription
Entity
Resources

RESOURCES
ResourceCode
ResourceName
Department

In such a simplistic model it is not hard to recognise what is what but that ONLY comes from an understanding of the Business Object structure and the Attribute names. Now imagine that instead of a few trivial Attributes.... you have 50 or 100 Attributes.... Good Luck remembering which are References at all let alone what type of Reference it is.
Additionally.... Imagine being deep in a Process and you need to FIND Resources for a particular Tenant... try building that Action and selecting from 100s of Attributes.

Essentially when navigating in this scenario, you are always looking for the Parent Business Object. Hence, if we had used PreFixes... then it is significantly easier...
The BOs look like this....

TENANT
TenantName
DateCreated
Status
om_Countries

COUNTY
Country
OfficeAddress
ob_Tenant
om_Entities

ENTITY
EntityCode
EntityDescription
ob_Country
om_Departments

DEPARTMENT
DepartmentCode
DepartmentDescription
ob_Entity
om_Resources

RESOURCES
ResourceCode
ResourceName
ob_Department

And navigating while buried in a Process requires not thinking AT ALL.... All you need to do is type ob in the inspector and the Parent BO is presented as the right choice for EVERY Level...

FIND Resource WHERE Resource.obDepartment.obEntity.obCountry.obTenant=ThisTenant

PointsWell

Just an asides in this.

You should probably avoid using _ as a separator. There is a bug that appears when you use have a ps and use an embedded form in the parent.

Jaymer

+1 to Mark for Prefixes

These prefixes will not be accepted/normal until adopted by Vlad.
And the Sample Applications will have to be re-written with this in mind.
People use those to start their apps - and doing so just propagates the "problem".
Newbies need to get off on the "right" foot when starting a new app
(assuming prefixes is the "right" way, and that is debatable according to some).

--> opens the door for shameless plug by mark

Woe is the Man
who decides to change his naming convention after starting cause Aware will screw up all your widgets... which is a barrier to rewrite in the first place.

Jaymer

TRUE, the colors won't solve everything, as nicely detailed by Mark.

But, if you have to go into someone's code that has NO naming conventions (ie. is similar to the demo Apps), then you're screwed.
The colors would certainly help trying to figure out whats going on.
(Along with the requested feature to ctrl-click on a process name to Edit it - so you don't have to weed thru the element tree trying to find it)

PointsWell

Jaymer wrote
Woe is the Man
who decides to change his naming convention after starting cause Aware will screw up all your widgets... which is a barrier to rewrite in the first place.

I went through the process of renaming ALL my relationship attributes (and BOs) to remove underscores. Aim is actually pretty good at capturing and promulgating the changes throughout (with the exception of HTML on forms).

It was about a day’s work and as long as you save after every single change it did not break my app. Don’t make 15 changes between saves - that will ruin your life, drain your bank account and cause you dog to pee under your desk*

your mileage may differ.

customaware

PointsWell wrote
There is a bug that appears when you use have a ps and use an embedded form in the parent.

Not aware of this. Surely we can get this fixed.

I am not changing all my apps.. no way 😉