3rd party skinning apps/solutions - what do you use?

[mskuma]

Hi

I am interested to explore ways to skin my apps - actually I mainly want to create custom system buttons that are much larger than normal for touch screen use, and reposition these on the bottom instead of the top of a form (not sure if that's possible) as well as the usual idea of custom forms.

I recently saw this topic which mentioned Skincrafter. I've seen other favourable reports about AppFace here. On the surface, both these apps appear to do the same thing except Skincrafter is US$300 and the other is US$90 (AppFace). There are others too.

I'd be interested to hear which tool you use & why - particular people who can explain the difference/benefits of the above costly tools compared to other methods.

Thanks very much.

[Trond]

Custom solution: Don't skin. It's ugly, slow and less functional.

[netmaestro]

I'm glad someone posted this, it's a chance for me to learn something. I don't understand window skinning, at least the full ramifications of using a skin. I don't use them at all. I do have a couple of "silly" apps that I put unconventional faces on, here is how I do it:

Code: Select all

Enumeration 
  #windowmain 
  #windowimage 
  #closebutton 
  #minimizebutton 
EndEnumeration 

UsePNGImageDecoder() 
CatchImage(#windowimage, ?windowface) 
OpenWindow(#windowmain,0,0,600,520,#PB_Window_BorderLess|#PB_Window_WindowCentered,"") 
SetWindowLong_(WindowID(#windowmain),#GWL_EXSTYLE,GetWindowLong_(WindowID(#windowmain),#GWL_EXSTYLE)|#WS_EX_LAYERED) 
SetLayeredWindowAttributes_(WindowID(#windowmain),RGB(255,0,255),0,1) 
CreateGadgetList(WindowID(#windowmain)) 
ButtonGadget(#closebutton, 290, 230, 80, 20, "Close") 
ButtonGadget(#minimizebutton, 290, 250, 80, 20, "Minimize") 

quit=0 
Repeat 
  EventID=WaitWindowEvent() 
  
  Select EventID 
    Case #PB_Event_ActivateWindow,#WM_PAINT
      StartDrawing(WindowOutput(#windowmain)) 
        DrawImage(ImageID(#windowimage),0,0) 
      StopDrawing() 
      InvalidateRgn_(WindowID(#windowmain),0,0) 
      UpdateWindow_(WindowID(#windowmain)) 
    Case #WM_LBUTTONDOWN 
      SendMessage_(WindowID(#windowmain), #WM_NCLBUTTONDOWN, #HTCAPTION, 0) 
    Case #PB_Event_Gadget 
      Select EventGadget() 
        Case #closebutton 
          quit = 1 
        Case #minimizebutton 
          ShowWindow_(WindowID(#windowmain),#SW_MINIMIZE)
     EndSelect 
  EndSelect 
Until quit 
End 

DataSection 
  windowface: IncludeBinary "testwindow.png" 
EndDataSection 

Here is the image to use for the windowface:

http://www.networkmaestro.com/testwindow.png

I would like it very much if someone "in the know" could explain what the difference between my approach and true window skinning is. I must be missing something, because I can't see where just this would be worth 300 bucks.

[Trond]

The thing is that with the 300-bucks solutions you get pre-made skinnable buttons, combo boxes, and such controls. But it's not really that hard to make yourself.

[ricardo]

The thing is that with the 300-bucks solutions you get pre-made skinnable buttons, combo boxes, and such controls. But it's not really that hard to make yourself.

Really??? Im NOT sure.

I think the skins i use, per example in AppFace are not the same as just draw some shape and some image to make my window.

I mean that real skining must change the no_client areas too (title bar per example).

Look this skins i use with AppFace














Did you know how to do this kind of skinning with PB without the need to use something like AppFace?

Note: This skins are NOT part of AppFace, are ones that i addapte to use it with that dll

[ts-soft]

I will see the skin, what i use in windows, not was the programmer like

[ricardo]

I would like it very much if someone "in the know" could explain what the difference between my approach and true window skinning is. I must be missing something, because I can't see where just this would be worth 300 bucks.

I guess the difference is that TRUE skinning is that it changes the non_client areas too and that uses real buttons, combobox, track bar, etc. but change the look.

THATS the hard part of skinning by yourself.

Using only some image with a no border windows its not the same and giving some shape to the window its not really skinning i think.

[Trond]

The thing is that with the 300-bucks solutions you get pre-made skinnable buttons, combo boxes, and such controls. But it's not really that hard to make yourself.

Really??? Im NOT sure.

I think the skins i use, per example in AppFace are not the same as just draw some shape and some image to make my window.

Did you know how to do this kind of skinning with PB without the need to use something like AppFace?

I didn't say I know everything that's easy. But drawing on the title bar isn't difficult at all, you just call GetWindowDC_() and voila you've got a device context to draw on. (Covers the client area, title bar, borders and everything.)
The controls are probably owner-drawn from a callback.

Edit: The usual, easiest and most flexible way is though to create a borderless window and draw the "title bar" on the client area.

[mskuma]

Custom solution: Don't skin. It's ugly, slow and less functional.

As I indicated in my opening mail, I am interested to explore it for functional reasons (e.g. touch screen), not asthetics. The typical windows buttons are not particularly functional on a touch screen. I'm thinking bigger buttons (close etc) in the title area that are down the bottom of the form instead of the top.. Anyway I think there is nothing wrong with skinning apps - e.g. look at most MP3 players.. many of these standout because they have a 'cool' look & feel - anyway I digress.. Thanks for your comment about 'borderless window'. I think it's the key - I believe purevision specifies that requirement to use their skinning method.

@netmaestro: thanks alot once again for sharing your experience & code. I am keen to study it. There are a couple of things I noticed from it - the edges of the window are not alpha-blended & the buttons are standard, not skinned. This is not a criticism - I'm not sure if alpha-blended edges are even possible.. I recall reading from the Skincrafter blurb that it supports alpha-blended windows, but not sure whether that is just the window are itself (i.e. partially transparent) or edges as well. Maybe this is where the extra cost is justified.

The impression obtained from the blurbs of these skinning apps is you get 2 things - (1) a DLL that facilitates the changes for you without extra coding on your part, and (2) a GUI skin-making app that lets you lay out parts of your skin against the various controls (e.g. buttons, progress bar, scroll bar etc) and packages these assets into one file for use with (1).

I'd say there is value in (2) for designers of all-encompassing and/or complex skins. For simpler skins, maybe (2) [and some may argue (1) also] is overkill. For any time-pressed situation to produce a non-standard window's form, these DLLs & tools are probably useful.

@ricardo: I think you introduced AppFace to the forum - thanks for your input. Sounds like you are happy with it. I wonder if you've had a chance to compare it to Skincrafter? If so I'd be glad to here your comment.

Anyway, I appreciate Trond's suggestion of GetWindowDC_(), I will try to search here for more info & examples.

Thanks for your insights so far!

[Fangbeast]

Trond said "Don't skin. It's ugly, slow and less functional" and I don't know if that's hie experience or a personal bias but I have found that it is simply not true as evidenced by more than one example in the forums and in the commercial world.

The simplest example I can give is one product that merely uses system theme overriding gradient colours to give itself a great, simple interface (no complex bitmap graphics). MediaMonkey.

If I could skin any off my apps to look that good, I would do it in a heartbeat because it's attractive and very fast.

That being said, I have seen applications with complex bitmap graphics just as fast as using gradient colour technology. I guess it comes down to the programmer's skills, available tools (possibly lots of money) and a customer request driven focus.

I get asked ALL the time for skinned applications by both private and corporate customers as even the business market is admitting that a more attractive interface keep their workers interested and happier (and therefore more productive) but I sadly lack the skill, the tools or the money to do so.

I shall have to go back to making butt-ugly applications and hope they still want them

[Trond]

Trond said "Don't skin. It's ugly, slow and less functional" and I don't know if that's hie experience or a personal bias but I have found that it is simply not true as evidenced by more than one example in the forums and in the commercial world.

The simplest example I can give is one product that merely uses system theme overriding gradient colours to give itself a great, simple interface (no complex bitmap graphics). MediaMonkey.

I can't see any of your gradients here. Either it's completely skinned or it uses some ugly mix of non-skinned mode and custom-draw mode to look like a normal Windows applications (fails miserably). I don't need a program that takes multiple seconds to quit and 30 mb of ram just to play my mp3s. There's also more than a "great" look, namely functionality. MediaMonkey cannot be used without a mouse, for example. Sure, keyboard navigation is not impossible nor even hard to make for skinned applications, however, the fact remains, that skinned applications almost never implements this properly.

[mskuma]

I don't need a program that takes multiple seconds to quit and 30 mb of ram just to play my mp3s. There's also more than a "great" look, namely functionality.

I think you have missed the point of my original post - as I wrote, I am all about functionality. Please refer me to the skinned app that takes up 30Mb & point out the rationale of why you think the skinned component takes up the bulk of the 30Mb.

[Trond]

I don't need a program that takes multiple seconds to quit and 30 mb of ram just to play my mp3s. There's also more than a "great" look, namely functionality.

I think you have missed the point of my original post - as I wrote, I am all about functionality. Please refer me to the skinned app that takes up 30Mb & point out the rationale of why you think the skinned component takes up the bulk of the 30Mb.

MediaMonkey takes up 30 mb. And I don't care what part of it takes up the 30 mb.
MediaMonkey is skinned and doesn't implement keyboard navigation fully. (Functional?)

Edit: Can you show me a skinned application with reasonable keyboard navigation?

[thefool]

Trond, go get FLStudio 6. All of it has great keyboard navigation etc etc.
Other software; Winamp.

Much more too

Many VST's too. SOME skinned app's are skinned bad. Some are not.

[mskuma]

MediaMonkey is skinned and doesn't implement keyboard navigation fully. (Functional?)

Edit: Can you show me a skinned application with reasonable keyboard navigation?

I appreciate your point, but you're also pressing this point to the point of irrelevance (at least for me anyway).. my application is a touch screen (without a keyboard BTW).. Also I think skinning doesn't necessary equal poor keyboard support. I've seen many regular applications that (e.g.) don't implement keyboard accelerators.

Edit: upon rethinking this (in a generic sense) - if skinning kills accelerators, I'd be concerned.