Daniel Keep wrote:
> 
> freeagle wrote:
>> Hello,
>>
>> Im quite new to D, but reading a lot of posts lately and checking some
>> websites about D i can say that the demand for good GUI API is quite
>> high in the community (including me).
>>
>> And i must say i agree with the idea of using OpenGL for making a cross
>> platform GUI. Having a modern GUI rendered using graphics hardware could
>>    drag more attention to D. And problem of not native look of such API
>> could be easily handled using different themes. When i checked Terra
>> project source, the actual style of the widgets takes only few lines of
>> code and a set of images. For me, OpenGL is the right way to go.
>>
>> Freeagle
> 
> Personally, I don't like these kinds of GUI toolkits.  Granted, they ARE
> more portable, and easier to write, but:
> 
> A) Visuals.  Not one single self-rendered toolkit I've ever seen has
> looked right.  GTK+, Swing... they all have small, subtle, but very
> annoying quirks that allow you to say: "Hey, this isn't a native app!"
> That should *never* happen.  Sun has had years to try to perfect this,
> and yet they haven't.
> 
> What is worse, what are you going to do about Vista?  When that comes
> out, all your work on the XP skin has to be re-done from scratch.  And
> even then, given that Vista uses all those transparency effects, will it
> even be possible without a major rewrite?

- actually, with a good design, it could be possible to add modify skins and themes with just a different set of images, maybe small code rewrite. Id never accept a toolkit that need to rewrite whole widget set for every available theme/skin it supports. About those transparency effects, OpenGL has alpha blending, so i dont see what major rewrites you are talking about. But i must say i havent tried vista yet, so im not even absolutely sure what transparency effects you are talking about.

> The problem is magnified if Vista has multiple themes.  Then you've got
> to support each one separately... you get the idea.
> 
> And let's not forget the million and one themes of KDE and GNOME...
> 
> B) Operation.  Under Windows, I sometimes use IMEs (Input Method
> Editors) to input text in Japanese.  Now, there's an option in Windows
> to enable extra support for this in text boxes... the problem is that if
> you're rendering the text boxes yourself, this support mysteriously
> disappears.  You will never be able to cover the entire set of system
> built-in functionality.  If you did manage to, you'd basically be
> re-implementing the entire toolkit API on every native system... which
> is much more work than just wrapping it in the first place.
> 
> That said, I still think projects like this are important.  For
> applications that don't care one whit if they "fit" with the system or
> not, they're a boon.  Such is true of things like media players, games,
> and other applications that intend to have a distinctive look (or don't
> need one at all :P)
> 
> But at the end of the day, I'd still prefer to have something like
> wxWidgets or SWT for D (in addition to toolkits like Terra), so that my
> programs will function properly :)
> 
> 	-- Daniel "Foolish Swing!  Everyone knows that Windows tree views have
> SQUARE swizzles, not round ones!  Your heinous deception is unmasked!" Keep
> 

- many of the features you mentioned can be achieved if you thoroughly design the toolkit before you start to code. I havent seen any terras design document, so i cant say how good is terra with this. Anyway, no toolkit can do everything, thats why there are plethora toolkits on the market. Everything has pros and cons

freeagle wrote:
> Daniel Keep wrote:
>> What is worse, what are you going to do about Vista?  When that comes out, all your work on the XP skin has to be re-done from scratch.  And even then, given that Vista uses all those transparency effects, will it even be possible without a major rewrite?
> 
> - actually, with a good design, it could be possible to add modify skins and themes with just a different set of images, maybe small code rewrite. Id never accept a toolkit that need to rewrite whole widget set for every available theme/skin it supports. About those transparency effects, OpenGL has alpha blending, so i dont see what major rewrites you are talking about. But i must say i havent tried vista yet, so im not even absolutely sure what transparency effects you are talking about.

AFAIK application windows in Vista have a < 50% alpha value and a lame distortion effect on the window title bars by default. It's easy to do these things in OpenGL. You can even create animated, multitextured backgrounds with bump mapping without any greater problems - even with a terrible widget set design.

-- 
Jari-Matti

Jari-Matti Mäkelä wrote:
> freeagle wrote:
>> Daniel Keep wrote:
>>> What is worse, what are you going to do about Vista?  When that comes out, all your work on the XP skin has to be re-done from scratch.  And even then, given that Vista uses all those transparency effects, will it even be possible without a major rewrite?
>> - actually, with a good design, it could be possible to add modify skins and themes with just a different set of images, maybe small code rewrite. Id never accept a toolkit that need to rewrite whole widget set for every available theme/skin it supports. About those transparency effects, OpenGL has alpha blending, so i dont see what major rewrites you are talking about. But i must say i havent tried vista yet, so im not even absolutely sure what transparency effects you are talking about.
> 
> AFAIK application windows in Vista have a < 50% alpha value and a lame distortion effect on the window title bars by default. It's easy to do these things in OpenGL. You can even create animated, multitextured backgrounds with bump mapping without any greater problems - even with a terrible widget set design.
> 

You most certainly can do those things in OpenGL.

Except Vista's desktop is composited using DirectX, so you can't simply "render" the window using OpenGL and expect it to blend with everything else.  Which means you would have to work out some way to grab all the pixels underneath the current window, and I'm not entirely sure how you would do that.

Of course, once you've done that, you can load the pixels into OpenGL, then render, and then... oh wait, Vista turns off desktop compositing as soon as you try to use OpenGL.  Which means as soon as you fire up your windowed OpenGL app... all the desktop compositing and Vista theme disappears.  Oops.  Now your program looks out of place anyway >_<

Unless of course Microsoft changes their mind about OpenGL... bloody monopolists... stupid DirectX...

Anyway, my original motive was more directed to the "we should make a self-rendered toolkit" vs "no!  we should make a native toolkit!" comments.  I think we need at least once of each, since there are things each toolkit can't really do.

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/

Daniel Keep wrote:
> 
> Jari-Matti Mäkelä wrote:
>> freeagle wrote:
>>> Daniel Keep wrote:
>>>> What is worse, what are you going to do about Vista?  When that comes
>>>> out, all your work on the XP skin has to be re-done from scratch.  And
>>>> even then, given that Vista uses all those transparency effects, will it
>>>> even be possible without a major rewrite?
>>> - actually, with a good design, it could be possible to add modify skins
>>> and themes with just a different set of images, maybe small code
>>> rewrite. Id never accept a toolkit that need to rewrite whole widget set
>>> for every available theme/skin it supports. About those transparency
>>> effects, OpenGL has alpha blending, so i dont see what major rewrites
>>> you are talking about. But i must say i havent tried vista yet, so im
>>> not even absolutely sure what transparency effects you are talking about.
>> AFAIK application windows in Vista have a < 50% alpha value and a lame
>> distortion effect on the window title bars by default. It's easy to do
>> these things in OpenGL. You can even create animated, multitextured
>> backgrounds with bump mapping without any greater problems - even with a
>> terrible widget set design.
>>
> 
> You most certainly can do those things in OpenGL.
> 
> Except Vista's desktop is composited using DirectX, so you can't simply
> "render" the window using OpenGL and expect it to blend with everything
> else.  Which means you would have to work out some way to grab all the
> pixels underneath the current window, and I'm not entirely sure how you
> would do that.
> 
> Of course, once you've done that, you can load the pixels into OpenGL,
> then render, and then... oh wait, Vista turns off desktop compositing as
> soon as you try to use OpenGL.  Which means as soon as you fire up your
> windowed OpenGL app... all the desktop compositing and Vista theme
> disappears.  Oops.  Now your program looks out of place anyway >_<
> 
> Unless of course Microsoft changes their mind about OpenGL... bloody
> monopolists... stupid DirectX...
> 
> Anyway, my original motive was more directed to the "we should make a
> self-rendered toolkit" vs "no!  we should make a native toolkit!"
> comments.  I think we need at least once of each, since there are things
> each toolkit can't really do.
> 
> 	-- Daniel
> 

- maybe i say something stupid, but...
- i suppose vista wants back compatibility with apps renderes with GDI. and GDI can do transparent stuff too. Actualy, both GDI and OpenGL work with the device context, which contains/points to (dunno the exact internals) to a pixel buffer hes connecte to. So you dont have to get all the pixels first, blend them and finally render them since they are already included in the device context. If they are not, i suppose theyd need a major rewrite of GDI too, and i dont think they can afford it. And i think that you can combine GDI rendering with Direct3D rendering, as well as GDI + OpenGL in current releases of Windows. So, i havent tried it yet, but i think that OpenGL + Direct3D could work too. Think Im going to find out :)

freeagle wrote:
> Daniel Keep wrote:
>>
>> Jari-Matti Mäkelä wrote:
>>> freeagle wrote:
>>>> Daniel Keep wrote:
>>>>> What is worse, what are you going to do about Vista?  When that comes
>>>>> out, all your work on the XP skin has to be re-done from scratch.  And
>>>>> even then, given that Vista uses all those transparency effects,
>>>>> will it
>>>>> even be possible without a major rewrite?
>>>> - actually, with a good design, it could be possible to add modify
>>>> skins
>>>> and themes with just a different set of images, maybe small code
>>>> rewrite. Id never accept a toolkit that need to rewrite whole widget
>>>> set
>>>> for every available theme/skin it supports. About those transparency
>>>> effects, OpenGL has alpha blending, so i dont see what major rewrites
>>>> you are talking about. But i must say i havent tried vista yet, so im
>>>> not even absolutely sure what transparency effects you are talking
>>>> about.
>>> AFAIK application windows in Vista have a < 50% alpha value and a lame distortion effect on the window title bars by default. It's easy to do these things in OpenGL. You can even create animated, multitextured backgrounds with bump mapping without any greater problems - even with a terrible widget set design.
>>>
>>
>> You most certainly can do those things in OpenGL.
>>
>> Except Vista's desktop is composited using DirectX, so you can't simply "render" the window using OpenGL and expect it to blend with everything else.  Which means you would have to work out some way to grab all the pixels underneath the current window, and I'm not entirely sure how you would do that.
>>
>> Of course, once you've done that, you can load the pixels into OpenGL, then render, and then... oh wait, Vista turns off desktop compositing as soon as you try to use OpenGL.  Which means as soon as you fire up your windowed OpenGL app... all the desktop compositing and Vista theme disappears.  Oops.  Now your program looks out of place anyway >_<
>>
>> Unless of course Microsoft changes their mind about OpenGL... bloody monopolists... stupid DirectX...
>>
>> Anyway, my original motive was more directed to the "we should make a self-rendered toolkit" vs "no!  we should make a native toolkit!" comments.  I think we need at least once of each, since there are things each toolkit can't really do.
>>
>>     -- Daniel
>>
> 
> - maybe i say something stupid, but...
> - i suppose vista wants back compatibility with apps renderes with GDI.
> and GDI can do transparent stuff too. Actualy, both GDI and OpenGL work
> with the device context, which contains/points to (dunno the exact
> internals) to a pixel buffer hes connecte to. So you dont have to get
> all the pixels first, blend them and finally render them since they are
> already included in the device context. If they are not, i suppose theyd
> need a major rewrite of GDI too, and i dont think they can afford it.
> And i think that you can combine GDI rendering with Direct3D rendering,
> as well as GDI + OpenGL in current releases of Windows. So, i havent
> tried it yet, but i think that OpenGL + Direct3D could work too. Think
> Im going to find out :)

Fair enough.  But like I was saying, if you want your toolkit to look like the host system, I imagine it would be easier to just wrap the system's API :P

That said, I've been doing some searching, and if you wanted to do borderless, translucent rendering in Windows, you might be able to get away with using GDI and "layered" windows.  Some interesting stuff in MSDN on it.

One of these days, I'll get around to writing that Konfabulator clone I've always wanted :P

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/