State-of-the Art Appearance with PB?

[Theo Gottwald]

Chris,

Stability is for my applications most important. Second thing is development time. If I think i cannot end a project, i will simply not start. Thats why I used your EZ-GUI for my last project, it really saved me time on some corners. And its perfectly stable until now.
And then third important is, can I sell this program i was doing at the end?.

Generally I would never trade Design versus stability because I am not marketing oriented from my character.
Like >90% of all PB Users. :-).
If I would be marketing oriented (would think of sales first then of quality and stability), you may not find me here but using Standard Programms from M$. Maybe bad luck for me, because marketing orientation sells better.

About your unstable WINLIFT-Plugin.
If you have third party components in your tools and they have stability problems, then its your task to contact their developers and together get these problems out of the world.  You can't leave this to your customers and say "its a third party tool maybe its their fault". Then its better, you don't talk about it so long it doesn't work.

If you have stability problems after a while, this could be resource problems, for example. In the easiest case this happens, if device context are not properly returned to the system.

As I am still developing under W2k, Resource problems show up easily on my PC and if these problems "come in the package" it would not be possible for me to develope my apps and at the same time search the problems of the tools I am using.
But if you get the things running, - lets say you get EZGUI-Windows look like those Patrice show up in his screenshots. This would be a big advantage for the end user.

I've also worked for big companies and yes they seem to not need nice GUI's.
As said, thats the case if you have already the contract from them or if they know you.

If they go on the market and there are several concurent products, wherever you go, often the bestlooking product with the same features is been taken at the end. Don't think the competitors do not have the same features.

About the "ownerdraw". I am not a designer, thats why I do not want to draw my controls myself ("Owner-draw" = the owner has to draw himself). We have 2008, if someone tells me that i have to draw my things myself to look competitive, I can only smile and say "thank you that you let me reinvent the wheel".

Paul is right, take a look here:
http://www.infragistics.com/dotnet/netadvantage/winforms.aspx

Then you'll see that even if I'd do that, i as a single person (with originally another thing in mind then to reinvent the wheel :-)) will not be able to do this things because I am not a designer. I think, even if I ownerdraw things, it may look rather worse then normal :-).

Its just a few years ago when we had the first generation of visul designer for PB. At  a time when the rest of the world had VS for several years. I know people are working on the next generation. I think it would make sense to jump one step and make the third generation to not always be one step behind the rest of the world.

[Patrice Terrier]

--Theo

Would you try this on your W2K computer?
http://www.jose.it-berater.org/smfforum/index.php?topic=1595.0

...

[Theo Gottwald]

It runs and produces two transparent windows on W2k.
Very elegant ... looks state-of-the art to me. Can say that this would suit me fine actually.

And as you said before - no matter how big the DLL's are I need for this.
Its just a question what project I am doing.

Something efficient? I can do it in PB.

Something for the public (must look elegant) ... don't know yet how to do it the easy way without reinventing dozens of wheels. :-)

[Charles Pegge]

Leaving aside complex controls like grids, much of the state-of-the-art design comes down to aesthetics and good artwork. We Humans like familiarity but not monotony. For neurological reasons, we find flat uniform surfaces (and sine wave tones) very tiring. So much of the contemporary look involves creating subtle shading and texturing of the surface - defocussing the inactive parts of the control and throwing functional parts into relief. Making  buttons and slider knobs look like 3d objects is more than just gimmickry - it allows us to use more natural modes of perception, that do not cause fatigue.

There is of course a fashion element to all of this. - The Spring collection of List boxes,knobs and scroll bars by  ... not to mention corporate styling.

[Chris Boss]

Theo,

The reason I deactivated the plugin for WinLift is because I didn't want end users using it because of instability issues. WinLift appears to work fine in EZGUI apps, but the designer does a lot more than the typical application and over time the instability appears. It has something to do with creating/destroying forms over and over again, that causes the problem to appear.

WinLift's source code is far too complicated for me to spend the time trying to find a solution.

Also it is not my responsibility to find solutions for every third party tool that could be used with EZGUI.
If I did that, I would have no time for my own development.

When it is practical and reasonable though, I do provide feedback to third party developers to make their tools better suited to use with EZGUI.

I gave suggestions for tools like EGrid which improved their use with EZGUI. In particular the importance of using the standard WM_NOTIFY syntax for events (which EZGUI supports).

As far as using ownerdraw, read the docs about using the "Simplified Ownerdraw" command set. It is simply a few lines of code (no API knowledge needed) and you can customize the look of any control which supports ownerdraw.

For example to create a color list combobox like this:



Is as simple as this:

Code Select Expand


SUB TBAR2_FONTCOLORS_Events( MyID&, CMsg&, CVal&, Cancel&)
     SELECT CASE CMsg&
          CASE %EZ_OwnerDraw
               EZ_DrawComboBox "TBAR2", MyID&, CVal&, 4, 0, "C"
          CASE %EZ_OwnerSize
               EZ_SizeComboBox CVal&, 4
          CASE ELSE
     END SELECT
END SUB


The items in the combobox simply are like this:

"<&HFFFFFF>  White"

Where the actual RGB color is a hex number in <> brackets.

EZGUI takes care of the rest and does the drawing for you.

The simplified ownerdraw command set does a number of interesting things and can be used for menus, listboxes, comboboxes and listviews.

As far as 3D colored buttons, the Designer supports them directly. Just click the FG or Bg color buttons in the controls property dialog and when a color is selected it automatically converts the button to ownerdraw and generates all the necessary code for them. There are also two button plugins, which can be used to change the look and feel of the buttons.

[Patrice Terrier]

In my case, the single factor that would make my decision to use a specific VS is:

Does it generates plain SDK source code or not?
Because i would avoid like the plague anything that is out of my control.

However i would be very glad to use a screen editor that would let me setup the control propreties like in VS2005/2008 and use my own graphic components to customize the aspect of the control (like in WinDev).

The WinDev screen editor, formaly HighScreen, is one of the best around, and if ever i have to collaborate on a VS PB project i would use it as the guidance to follow, including the way the code is tied to the control.

...

[Theo Gottwald]

Reading the todays posts, I can agree to anyone who write here.
Or let me say it like that: We are all the same opinion on the points discussed.
In this case the discussion will soon be boring :-). hehe

Charles is right, there are elements of fashion in the design - not only of our clothes but also of our Apps and GUI's.

Chris is right about what he writes, but that doesn't remove the need for proffessional Designers (humans)
to generate really good looking stuff (see my link from the first post, Chris).
I know these possibilities are there and they save time for Apps to look a bit less grey.
But there is no switch for Glas and Aero and the Controls are not like those in the link.

About WinLift and Instability. Until I am completely shure, that its fully integrated and works 100% - even if the forms are 1000 times moved and removed, I won't use it. Because if I get resource problems because Memory is not properly freed the beauty is gone for me .-). As said, WinLift looks great, but it would be needed to be fully integrated somewhere to be more easy usable.
Could be a EZ-GUI Special Editon, but must be 100% stable - or no deal.

Also I agree that you as a single person cannot keep all combinations of how your tools "tested and bug free".
Thats why my word shall motivate you all to make more cooperations. Make something together.
Share your tools and ideas and get state-of-the art products out there.

And finally Partice ... I said already that I will look a closer look on this WinDev.
I will need something to make GUI's for my PB Programms. GUI's that are really competitive and not just mediocre.
Actually the amount of work using PB would be maybe to high.

[Patrice Terrier]

About WinLift and Instability

Well i would like to say that WinLIFT is rock solid for me (all my commercial applications are using it).

Indeed there are two WinLIFT flavors, one works like the zSkin.inc i did share with you, and one works as a subclassing engine to skin existing controls on the fly, and both are ownderdrawn based.
The problem with the subclassing engine is that it must decipher the class being used to skin the control properly, ie: if the class name is "Button" I know what to do, but in case of superclass or private control using unknown name i don't know what to do.

In the case of EZGUI i had to do this:

       IF LEFT$(UCASE$(zTxt), 6) = "EZGUI_" THEN
          EffectType& = %SKEFF_SCREENSHOT
       END IF

of course this is not viable in the long run to support each of the VS using their own class name.
Hence the reason why i give it up.

But of course i know how to do it in case of a dedicated VS project, he he!


Here is how the WSA works to decode the class being used (WSA = WinLIFT Simplified API)

Code Select Expand


FUNCTION EnumChildProc(BYVAL hWnd&, BYVAL lParam AS LONG) AS LONG
    LOCAL bt          AS SKALL
    LOCAL rc          AS RECT
    LOCAL cs          AS COLORSCHEME
    LOCAL pt          AS POINTAPI
    LOCAL zChildClass AS ASCIIZ * 32

    IF GetClassName(hWnd&, zChildClass, SIZEOF(zChildClass)) THEN
       hParent& = GetParent(hWnd&)
       ItemParent& = skItem(hParent&)
       zChildClass = UCASE$(zChildClass)
       MDICLIENT$ = "MDICLIENT"
       IF INSTR(zChildClass, MDICLIENT$) THEN zChildClass = MDICLIENT$

     ' May I skin the control?
       IF NOT skSkinActive(hWnd&) THEN FUNCTION = %TRUE: EXIT FUNCTION

       SELECT CASE CONST$ zChildClass
       CASE "MDICLIENT"
            IF GetParent(hParent&) = 0 THEN Win(ItemParent&).hMdiClient = hWnd&
            CALL DeleteObject(SetClassLong (hWnd&, %GCL_HBRBACKGROUND, CreateSolidBrush(skGetSysColor(%SKCOLOR_INACTIVECAPTION))))
          ' Should we handle this big mess
            CALL skMonitorCtrl(hWnd&, %CTRL_MDICLIENT)

       CASE "TOOLBARWINDOW32"
            IF GetParent(hParent&) = 0 THEN
               CALL skMonitorCtrl(hWnd&, %CTRL_TOOLBAR)
               cs.dwSize = SIZEOF(COLORSCHEME)
               cs.clrBtnHighlight = skGetSysColor(%SKCOLOR_3DRIGHTBOTTOM)
               cs.clrBtnShadow = skGetSysColor(%SKCOLOR_3DLEFTTOP)
               CALL SendMessage(hWnd&, %TB_SETCOLORSCHEME, 0, BYVAL VARPTR(cs))
            ELSE
               CALL skMonitorCtrl(hWnd&, %CTRL_TOOLBAR)

               cs.dwSize = SIZEOF(COLORSCHEME)
               cs.clrBtnHighlight = skGetSysColor(%SKCOLOR_3DRIGHTBOTTOM)
               cs.clrBtnShadow = skGetSysColor(%SKCOLOR_3DLEFTTOP)
               CALL SendMessage(hWnd&, %TB_SETCOLORSCHEME, 0, BYVAL VARPTR(cs))

               CALL DeleteObject(SetClassLong (hWnd&, %GCL_HBRBACKGROUND, BYVAL %NULL))
               CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) OR %WS_EX_TRANSPARENT)

               Child(skChild(hWnd&)).paintflag = %TRUE
            END IF

       CASE "MSCTLS_STATUSBAR32"
            CALL skMonitorCtrl(hWnd&, %CTRL_STATUS)
            CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) OR %WS_EX_TRANSPARENT)

            IF ItemParent& THEN Win(ItemParent&).hStatus = hWnd&

       CASE "BUTTON"
            WasStyle& = GetWindowLong(hWnd&, %GWL_STYLE)
            IF (WasStyle& AND %BS_GROUPBOX) = %BS_GROUPBOX THEN
               CALL GetClientRect(hWnd&, rc)
               CALL skMonitorCtrl(hWnd&, %CTRL_GROUPBOX)
               CALL SetRect(Child(skChild(hWnd&)).rc, 0, 0, rc.nRight, rc.nBottom)

               CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) OR %WS_EX_TRANSPARENT)

            ELSEIF (WasStyle& AND %BS_CHECKBOX) = %BS_CHECKBOX THEN
               UseStyle& = %CTRL_CHECKBOX
               IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
                  UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
               END IF
               CALL skMonitorCtrl(hWnd&, UseStyle&)
            ELSEIF (WasStyle& AND %BS_AUTOCHECKBOX) = %BS_AUTOCHECKBOX THEN
               UseStyle& = %CTRL_CHECKBOX
               IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
                  UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
               END IF
               CALL skMonitorCtrl(hWnd&, UseStyle&)
            ELSEIF (WasStyle& AND %BS_RADIOBUTTON) = %BS_RADIOBUTTON THEN
               UseStyle& = %CTRL_RADIOBUTTON
               IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
                  UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
               END IF
               CALL skMonitorCtrl(hWnd&, UseStyle&)
            ELSEIF (WasStyle& AND %BS_AUTORADIOBUTTON) = %BS_AUTORADIOBUTTON THEN
               UseStyle& = %CTRL_RADIOBUTTON
               IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
                  UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
               END IF
               CALL skMonitorCtrl(hWnd&, UseStyle&)
            ELSE
               IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
                  CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON + %CTRL_OWNERDRAWN)
               ELSEIF (WasStyle& AND %BS_ICON) = %BS_ICON THEN
                  CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON + %CTRL_OWNERDRAWN)
               ELSEIF (WasStyle& AND %BS_BITMAP) = %BS_BITMAP THEN
                  CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON + %CTRL_OWNERDRAWN)
               ELSE

                  CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) XOR %WS_EX_DLGMODALFRAME)

                  Label$ = skGetCTLText(hWnd&)
                  ID& = GetDlgCtrlID(hWnd&)
                  EnableMode& = IsWindowEnabled(hWnd&)
                  IF ID& >= %ID_DOCKOUT AND ID& <= %ID_CLOSE THEN ID& = 0
                  IF ID& THEN
                     CALL GetWindowRect(hWnd&, rc)
                     xBut& = rc.nLeft
                     yBut& = rc.nTop
                     ButWidth& = rc.nRight - rc.nLeft
                     ButHeight& = rc.nBottom - rc.nTop
                     CALL SetWindowLong(hWnd&, %GWL_STYLE, WasStyle& OR %BS_OWNERDRAW)
                     bt.Button = 1
                     UseFont& = SendMessage(hWnd&, %WM_GETFONT, 0, 0): IF UseFont& = %NULL THEN UseFont& = skDefaultFont
                     CALL skDrawBut3D(hWnd&, Label$, UseFont&, ButWidth&, ButHeight&, bt)
                     CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON)
                  END IF
               END IF
            END IF

       CASE "SYSTABCONTROL32"
            CALL skMonitorCtrl(hWnd&, %CTRL_TAB)
            CALL DeleteObject(SetClassLong (hWnd&, %GCL_HBRBACKGROUND, GetSysColor(%COLOR_3DFACE)))
            CALL GetWindowRect(hWnd&, rc)
            xOffset& = rc.nLeft: yOffset& = rc.nTop
            XX& = rc.nRight - rc.nLeft: YY& = rc.nBottom - rc.nTop
            CALL SendMessage(hWnd&, %TCM_ADJUSTRECT, %FALSE, BYVAL VARPTR(rc))
            hRgnClip& = CreateRectRgn(0, 0, XX&, YY&)
            xOffset& = rc.nLeft - xOffset&: yOffset& = rc.nTop - yOffset&
            XX& = rc.nRight - rc.nLeft: YY& = rc.nBottom - rc.nTop
            hRgn& = CreateRectRgn(xOffset&, yOffset&, xOffset& + XX&, yOffset& + YY&)
            CALL CombineRgn(hRgnClip&, hRgnClip&, hRgn&, %RGN_DIFF)
            CALL skDeleteObject(hRgn&)
            CALL SetWindowRgn(hWnd&, hRgnClip&, %TRUE)

       CASE "#32770"
            CALL skMonitorCtrl(hWnd&, %CTRL_DIALOG)

       CASE "STATIC"
            CALL skMonitorCtrl(hWnd&, %CTRL_STATIC)
            IF SendMessage(hWnd&, %WM_GETFONT, 0, 0) = %NULL THEN ' Bernard
               CALL PostMessage(hWnd&, %WM_SETFONT, skDefaultFont, 0)
            END IF

       CASE "SYSTREEVIEW32"
            CALL skMonitorCtrl(hWnd&, %CTRL_SYSTREEVIEW)
            UseColor& = skGetSysColor(%SKCOLOR_CAPTIONTEXT)
          ' Check if UseColor& doesn't conflicts with the &hFFFFFF transparent background
            IF UseColor& = &hFFFFFF THEN UseColor& = RGB(250,250,250) ' RGB(255,255,254)
            CALL SendMessage(hWnd&, %TVM_SETBKCOLOR, 0, &hFFFFFF)
            CALL SendMessage(hWnd&, %TVM_SETTEXTCOLOR, 0, UseColor&)
            CALL SendMessage(hWnd&, %TVM_SETLINECOLOR, 0, UseColor&)

       CASE "LISTBOX"
            WasStyle& = GetWindowLong(hWnd&, %GWL_STYLE)
            IF (WasStyle& AND %LBS_HASSTRINGS) THEN
               CALL skMonitorCtrl(hWnd&, %CTRL_LISTBOX)
            END IF

       CASE "MSCTLS_TRACKBAR32"
            CALL skMonitorCtrl(hWnd&, %CTRL_TRACKBAR)

       CASE "SYSLISTVIEW32"
            CALL skMonitorCtrl(hWnd&, %CTRL_LISTVIEW)
            CALL SendMessage(hWnd&, %LVM_SETBKCOLOR, 0, skGetSysColor(%SKCOLOR_INACTIVECAPTION))
            CALL SendMessage(hWnd&, %LVM_SETTEXTCOLOR, 0, skGetSysColor(%SKCOLOR_CAPTIONTEXT))
            CALL SendMessage(hWnd&, %LVM_SETTEXTBKCOLOR, 0, skGetSysColor(%SKCOLOR_INACTIVECAPTION))

       CASE "SYSHEADER32"
            LOCAL pHD AS HD_ITEM
            HeaderCount& = SendMessage(hWnd&, %HDM_GETITEMCOUNT, 0, 0)
            IF HeaderCount& THEN ' Check if we can skin it or not
               DoIt& = -1
               FOR K& = 0 TO HeaderCount& - 1
                   pHD.Mask = %HDI_FORMAT
                   CALL SendMessage(hWnd&, %HDM_GETITEM, K&, VARPTR(pHD))
                   IF (pHD.fmt AND %HDF_OWNERDRAW) = %HDF_OWNERDRAW THEN DoIt& = 0: EXIT FOR
                   IF (pHD.fmt AND %HDF_BITMAP) = %HDF_BITMAP THEN DoIt& = 0: EXIT FOR
                   IF (pHD.fmt AND %HDF_BITMAP_ON_RIGHT) = %HDF_BITMAP_ON_RIGHT THEN DoIt& = 0: EXIT FOR
                   IF (pHD.fmt AND %HDF_IMAGE) = %HDF_IMAGE THEN DoIt& = 0: EXIT FOR
               NEXT
               IF DoIt& THEN CALL skMonitorCtrl(hWnd&, %CTRL_SYSHEADER)
            END IF

       CASE "RICHEDIT"
            CALL skMonitorCtrl(hWnd&, %CTRL_RICHEDIT)

       CASE ELSE
            CALL skMonitorCtrl(hWnd&, %CTRL_UNDEFINED)

       END SELECT
    END IF
    FUNCTION = %TRUE   ' continue enumeration of children...
END FUNCTION


The problem of Chris, is that WSA was not designed to change its graphic components on the fly (it does this only once, during process initialization).
This must be handled like in the WinLIFT standard version using native's WinLIFT controls.
Or like VS2005/2008 or WinDev does, each of the control could have an associated bitmap, when you select the customize property (ownerdrawn).

...

[Theo Gottwald]

Can't you explain it directly to Chris, so he can integrate it in EZGUI - how it is meant to be - ?

This would be a very good combination to the advantage of you both.
But there should be a really good integration which is absolutely stable.

A halfstable "just run it once" thing or something where I need to walk extra rounds to get the advantages is not what I need.
Such half done bussiness is worse then nothing.

And me as potential customer cannot be asked to repair things not made complete at design time, unless its been released as freeware :-).

[Patrice Terrier]

--Theo

As i said already, i would be glad to cooperate with a tool looking like the visual designer of VS or Windev, as long as it is able to produce plain SDK code, but anything else I am not interrested in, and this would also apply to DDT and the CreateDialog API.

...

[Chris Boss]

Theo,

It is not a matter of either product being unstable, but that they were not intended to work together.

Like I said, WinLift works fine at first, but when loading and unloading forms in the designer, winlift develops an instability and can GPF.

Like Patrice said, WinLift was not designed for such use.

The effort to make two totally different products like these compatible would require a lot of effort.
Its different with say custom controls, because they are designed to be used by other software. If they are designed correctly, then compatibility is rarely a problem.

WinLift on the other hand "takes control" of things and by subclassing overrides default actions of the calling app.
This likely requires specific "rules" in how this is done.

I found that the problem with WinLift appears to be that it didn't like other windows (dialogs) being created which are not skinned, while using the skin engine for the rest (the projects forms). I guess if I let winlift skin the entire designer, that might make a difference so all the windows are skinned. I didn't try that and neither did I want to, because most customers don't use winlift and the designer was made to work with the standard look and feel of windows.

I guess it would be possible to make a purely winlift edition of the designer. I don't know if that would work or not.

[Theo Gottwald]

Ok, Chris, I think this explanation shows me where we think the problem is.
WinLift expects the whole Designer app to be skinned.

I think we can drop that now, while EZ_GUI is more near to SDK-Code then DDT,
but its not plain SDK therefore Patrice will not be interested in this case a lot.

As a conclusion, on this topic, I'd say that we just wait and see if any of the developers sees the need for a competitive design in the future and makes it easy to geth hands on this design.

In my actual project its not intersting, therefore i have no real hurry on that.

[Donald Darden]

I;m not a graphics designer, but I can tell you that if you want to see PowerBasic or any other compiler become graphics centric, you have a real problem, because what's visual and what does on underneath are two distinctly different things.  First of all, the traditional way to program has been to analyze the task and code it as an algorythm, which takes the form of a programming language, and that consists of logic, determinants, values, constants, and branches, all expressed as written words and numerical symbols.

But graphics are... well, graphical.  It was a real advance to find a way to express graphical elements as tags, because now they are insertible into written structures, and these can be made part of a programming language, and we do this with web pages.  But have you looked at the horrible mess that results?  Try to read your way though the source code for a web page and see if you can make that relate to the visual appearance and behavior of the page as seen.  It has taken us decades to finally narrow the interpretations of html documents so that all browsers pretty much view them the same, but with some minor variations still.  Yet there are always some sites that one browser or another may not display or react to properly.  And now we see XML and AJAX (among other technologies) trying to take center stage.

What we are saying, is that to do these things, you have to learn to do these things.  Graphical Designers learn their trade the hard way, and the problem is, for what you gain, few people want to have to make the same journey.  So instead we ask the Graphical Designers, can't you guys find a way to make it simple for the rest of us?  And the answer is, that they can write software that we can incorporate into our own products, but you still have to learn to use it, and in fairness you need to pay additional to get it.

To learn graphics, you have to master new concepts.  A part of this is learning things, like the names of controls, parameters, and constants.  These have to become part of our language and thought processes.  To avoid doing this, we would have to follow a different path entirely, meaning we would have to get away from words and tags and instead resort to... graphics.

What if we could visually design things?  This is what lead to Visual Basic, PBForms, DDT, and other tools.  They were made simple so that we could master them.  But now average programmers are forced to compete with Graphics Designers for customers, asnd the programmer is coming off second best, because the part he labors the hardest over is not visible.  Instead, he is being asked to put more effort into the visual part, and he finds that unfair, and a real threat to his overall productivity.

So how do we resolve this?  I really don't know.  I do know that as long as everyone takes a different road towards a solution, we end up with a fragmented market.  So the idea that Graphical Designers should band together to benefit the programmer base has merit, in that a common appoach would be better at the onset.  But thje other thing, is that to ask programmers to take the long road of learning concepts and language skills for doing graphics is not going to be the easy or quick way.

I think the right approch has to center on using graphics to illustrate choice, then selecting the effects desired.  Suppose you consider a single image that you were working on in a graphics manipulation program, possibly a photo editor.  You have the many choices of changing the gray scale, hues, saturation, contrast, brightness, and so on.  A good editor might preview what some of the effects could do at different settings wieh a series of thumbnail images.  If you see an effect you like, you could either select that, or adjust a scale to get you in the vicinity of looking like that.  After that, you could save your work, and immediately see more choices of how the image could be further refined.

Now think of an object that is a composite of visual aids and controls.  You want the ability to modify both, at the same time, and continue to see how they interact with each other.  You need the ability to interact as though a user, as the graphics developer, and where necessary, at the lowest coding level, and to be able switch between these views with ease.

If someone were to devise the engine for managing all this, then perhaps other developers can see their way to go after effects that can be modulated to work with this engine.  Now that is an approach that might help bring developers together in a common purpose.

[Theo Gottwald]

We strongly believe that, from the user's point of view,
your application's appearance is the biggest single factor that can make the difference
between your product and that of your competitors.

I think this sentence is woth a quote and a good end for the post.
It says in one sentence what I would like to have with PB also.

[Edwin Knoppert]

I think that is only partially true..
I think this is a programmers perspective.