Re: About Creating New Packages/Widgets & Other Dev Help

> On Jan 3, 2016, at 1:35 AM, Metallicow <[email protected]> wrote:
> 
> 
> 
> On Tuesday, December 29, 2015 at 4:00:19 PM UTC-6, kevino wrote:
> 
> 
>> On Dec 28, 2015, at 6:54 PM, Metallicow <[email protected] <javascript:>> wrote:
>> 
>> 
>> 
>> On Saturday, December 26, 2015 at 11:33:06 AM UTC-6, [email protected] <http://theolliviers.com/> wrote:
>> 
>> Are you using a series of controls with sizers to do the layout for a custom-drawn button? 
>> 
>> Regards,
>> 
>> Kevin
>> 
>> 
>> Nope. ShapedBitmapButton is just a hand-built wx.Control Subclass.
>> So 1 Button instance is just like 1 Button instance when created. This way it is a dropin replacement basically.
>> ShapedBitmapButtonAdv is a subclass of ShapedBitmapButton
>> With the advanced techniques the button instances "talk" or "discuss" with each other about what event is really going on and how to draw. Then process the event 
>> which in turn `not really` "walks back down the tree" and redraws the original button correctly as if that instance is the actual instance.
>> I have tested the basic class with absolute positioning and have tests for all the different sizers, so the basic class is pretty solidly tested.
>> I guess it could be explained like this also... ummm
>> The event has to be recreated exactly(signed by the lead) and passed around like a charter to sign basically...
> 
> Gotcha. This just seems a fairly complex system to draw some buttons, and I'm wondering what issue exactly this system was built to resolve. Is this the overlap thing you mentioned earlier? wx.DC uses very dated APIs on Windows that don't support a lot of modern drawing operations, and so sometimes very simple drawing tasks become a huge hassle to implement. Multi-control transparency particularly can be a huge headache because the Win implementation of wx.DC uses APIs that really pre-date transparency support entirely. (MS bolted on some transparency support later, but it only works in certain circumstances.) Often, you can get better results simply by using wx.GraphicsContext or, as Chris mentioned in another thread, wx.GCDC if you want to get the good stuff but keep your code as-is.
> 
> Regards,
> 
> Kevin
> 
>> -- 
>> You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> 
>  
> I have been thinking about duplicating/tweaking the class to test with wx.GraphicsContext and or wx.GCDC but haven't got there yet.
> I'll have to read up on the differences between them and test/see if there is any visual or performance differences at that point.
> ... But yea, the classes are built overall for overlap/overlaying issues and alpha drawing(The image is the button, not the alpha), that way I can make just about anything...

Basically, when you use wx.GraphicsContext or wx.GCDC, it is like using wx.BufferedPaintDC to draw into an offscreen buffer first, but the buffering is done by the OS itself. When drawing is buffered, you get alpha buffering "for free". Handling controls with transparency is no different from drawing any other control, often you just have to set an alpha value for the drawing operations you want to have some level of alpha. When the OS draws the overlapping controls to screen, it automatically applies any alpha transparency. If done right using wx.GCDC, I suspect you could delete all the event forwarding code and it would work the same, though I'm not 100% certain because Win APIs can be pretty wonky at times. 

Also, if this code is intended to be cross-platform, you might want to get someone to try your code on Mac if you haven't already, as well as Linux. My guess is that your workarounds assume that all drawing is painted directly to the screen, which is true for wxWidgets on Windows but not on Mac (the OS buffers all drawing on Mac), and I am pretty sure also sometimes not on Linux either.

Regards,

Kevin

> For example, the python Qt demo has a demo where the layout images/widgets(absolute positioning) animate when a button is clicked and fly off screen while the new widgets
> fly in to create the "next page layout". That is entirely possible at this point.
> Other fancy examples might be a slide in/over the top HUD like a lot for video games have for options screens, etc...
> ... It could even go as far as making a "web page" lookalike.
> It just really depends on the artists good looking art and how far they want to take it with the level of detail. 
> ...And when I get it 99.9% finalized in python someday... Then if I can manage to grok/port it into C++ correctly which will really speed up the drawing performance, that would be awesome.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.