"John Reimer" <brk_6502@yahoo.com> wrote in message news:d660u9$1u3t$1@digitaldaemon.com...
> Burton Radons wrote:
>
>>>
>>> Actually, things a high level as these would be specific to the widget system (QT, GTK, etc...)  It'd be much easier to use whatever is already in Harmonia.
>>
>>
>> I wouldn't use the library if it didn't use the native widget (or at least have an option to use it) for file selection - getting this right is not an easy task, as the long-time suckitude of Unix file selectors (and to be fair, Windows file selectors before Windows 98) show.
>
> Each to his own.  I think we need a selection of GUI toolkit types. Harmonia is one of them.  People might say the same about the FLTK.  But non-native widget toolkets serve a very useful purpose in many different types of projects, I'm sure.

Agreed. The only one here:
It would be extremely nice if such toolkits will use
sort of common ground. E.g. Harmonia.Graphics.
This will allow to share components and code, HTML engine for example.

I am personally don't like to be in single choice situations but some unification of basic things is definitely a good thing.

>
> Other projects are already taking the native widget set design direction. It's just nice to have a choice; and Harmonia, so far, is hands down one of the most pleasing to look at.  I, for one, welcome it.

Thanks.

One more. I did some analytical research about
GUI - almost 85% of application of common use do not
require system widgets at all. Just set of simple ones like in Harmonia.
Take a look on the Internet - applications there use 6..10 builtin
HTML widgets (but main problem that this set is fixed and cannot
be naturally and easily extended).
I would say that D and Harmonia are way to go for applications
having web style GUI.
See:
http://www.winplanet.com/img/screenshots/scr-nav2004-1.gif .
Easy as piece of cake, right? :)


>
>> Just consider how to support a hotplugged pen drive/camera/PSP.  With the default widget you don't have to think about it; it knows how to create the necessary crazy file paths, not just for Windows XP, but for all previous versions of Windows that support hotplugging.
>
> Good point.  This is more the case on Windows XP.  On Linux/Unix, compatibility is so unattainable/unreliable as to make the issue moot.

<IMHO> This is why Linux/Unix is not a consumer platform.</IMHO>
Lack of common standards. (Probably because of its GPL nature? :-P  )
I wish D community to stay away from such fuzziness.
E.g. I would like to see joined forces in design of unified template
container/algorithm library (But I have doubts - do we need this at all?)
At least Phobos *MUST* be rock solid, simple and must not shine by lights
of different approaches and name conflicts as an XMas tree.
Probably it is a right time to revisit its design?

On Sat, 14 May 2005 13:07:16 -0700, Andrew Fedoniouk wrote:

> In harmonia.ui.native.win32.* package
> I am using simple naming convention instead:
> 
> all functions with names starting with 'native...' needs to be ported as they seen from generic packages. The same is valid for class names: e.g. NativeImage is a class visible and used by generic code.
> 

This system actually works quite well.  With this naming convention in place, a simple "version" statement where the "import harmonia.ui.native.*" is executed is all that's required.


> 
> There are four native modules and six and only six generic modules importing them.
> 
> harmonia.ui.window -> harmonia.ui.native.win32window
> harmonia.ui.graphics -> harmonia.ui.native.win32graphics
> harmonia.ui.images -> harmonia.ui.native.win32graphics
> harmonia.ui.application -> harmonia.ui.native.win32application
> harmonia.ui.exchange.clipboard -> harmonia.ui.native.win32exchange
> harmonia.ui.exchange.dnd ->  -> harmonia.ui.native.win32exchange (planned,
> not in distribution)
> 
> This list is frozen and highly probable will not be changed in future.
> 
> All other modules do not use any native* functions nor classes now and beyond.
> 

Nice.  It is a simple and effective solution.  But looking over the native functions, I now see that there is a fair bit of work involved in the porting process.  An X11 could take awhile, especially since the need is there for a considerable amount of low-level X knowledge to perform the equivalent to the win32 version.

-JJR

>
> Nice.  It is a simple and effective solution.  But looking over the native functions, I now see that there is a fair bit of work involved in the porting process.  An X11 could take awhile, especially since the need is there for a considerable amount of low-level X knowledge to perform the equivalent to the win32 version.
>

Let me know about problems, my knowledge of X11
is rather theoretical than practical but in any case
two heads are better than one.

Andrew.

Andrew Fedoniouk wrote:
>>Nice.  It is a simple and effective solution.  But looking over the native
>>functions, I now see that there is a fair bit of work involved in the
>>porting process.  An X11 could take awhile, especially since the need is
>>there for a considerable amount of low-level X knowledge to perform the
>>equivalent to the win32 version.
>>
> 
> 
> Let me know about problems, my knowledge of X11
> is rather theoretical than practical but in any case
> two heads are better than one.
> 
> Andrew. 
> 
> 

No worries... You'll be my very first resource when trouble brews! ;-)

>
>Nice.  It is a simple and effective solution.  But looking over the native functions, I now see that there is a fair bit of work involved in the porting process.  An X11 could take awhile, especially since the need is there for a considerable amount of low-level X knowledge to perform the equivalent to the win32 version.
>
>-JJR

The Wine people know a lot about this subject: www.winehq.com

Mark T wrote:
>>Nice.  It is a simple and effective solution.  But looking over the native
>>functions, I now see that there is a fair bit of work involved in the
>>porting process.  An X11 could take awhile, especially since the need is
>>there for a considerable amount of low-level X knowledge to perform the
>>equivalent to the win32 version.
>>
>>-JJR
> 
> 
> The Wine people know a lot about this subject:
> www.winehq.com
> 
> 

Oh!  I forgot about that resource.  Thanks, I'll take a look.  I've been scrounging on the internet for the last several days for X11 programming information, especially XLib, XRender, Xft, and XComposite.  Information on the latter three is very difficult to collect, which is annoying. I've also starting investigating other projects for implementation examples: fltk, SDL, and GLFW.  The last two are limited because they don't provide a intrinsic widget set.

From what I see, Xlib stuff is fairly straight-forward, perhaps even more so than win32 GDI.  Whereas, if we want to get Alpha blending operations working easily, Xft, XRender, or XComposite (extensions) are important candidates.  Manual alpha blending is possible and if I'm not mistaken, I think that's what Harmonia does (Andrew?) on win32.

Once I've got a basic understanding of Harmonia's design and more understanding of X11, I'll start parleing with Andrew about how to go about this.

Thanks again for the wine suggestion.  That could be a very useful resource.

-JJR

"John Reimer" <brk_6502@yahoo.com> wrote in message news:d6nhp6$4vt$1@digitaldaemon.com...
> Mark T wrote:
>>>Nice.  It is a simple and effective solution.  But looking over the
>>>native
>>>functions, I now see that there is a fair bit of work involved in the
>>>porting process.  An X11 could take awhile, especially since the need is
>>>there for a considerable amount of low-level X knowledge to perform the
>>>equivalent to the win32 version.
>>>
>>>-JJR
>>
>>
>> The Wine people know a lot about this subject: www.winehq.com
>>
>>
>
> Oh!  I forgot about that resource.  Thanks, I'll take a look.  I've been scrounging on the internet for the last several days for X11 programming information, especially XLib, XRender, Xft, and XComposite.  Information on the latter three is very difficult to collect, which is annoying. I've also starting investigating other projects for implementation examples: fltk, SDL, and GLFW.  The last two are limited because they don't provide a intrinsic widget set.
>
> From what I see, Xlib stuff is fairly straight-forward, perhaps even more so than win32 GDI.  Whereas, if we want to get Alpha blending operations working easily, Xft, XRender, or XComposite (extensions) are important candidates.  Manual alpha blending is possible and if I'm not mistaken, I think that's what Harmonia does (Andrew?) on win32.

alpha blending is platform independent as it is implemented in D code. Nothing spectacular.

>
> Once I've got a basic understanding of Harmonia's design and more understanding of X11, I'll start parleing with Andrew about how to go about this.

Ok.

>
> Thanks again for the wine suggestion.  That could be a very useful resource.

Yep, Wine approach might work.
I did some tests - it is close.

In fact Harmonia Win32 applications should work 'as is' under the Wine.

>
> -JJR

Andrew Fedoniouk wrote:

>>
>>From what I see, Xlib stuff is fairly straight-forward, perhaps even more so than win32 GDI.  Whereas, if we want to get Alpha blending operations working easily, Xft, XRender, or XComposite (extensions) are important candidates.  Manual alpha blending is possible and if I'm not mistaken, I think that's what Harmonia does (Andrew?) on win32.
> 
> 
> alpha blending is platform independent as it is implemented
> in D code. Nothing spectacular.
> 
> 


Yeah... that's what I figured.  That's good then because it means I don't have to worry about it.  It makes it much simpler.  But in the future wouldn't it be a good idea to adopt an accelerated platform dependent approach?  It's still hidden in the native classes.  For now, I best keep it out of mind so I don't get overwhelmed with X extensions.



>>Once I've got a basic understanding of Harmonia's design and more understanding of X11, I'll start parleing with Andrew about how to go about this.
> 
> 
> Ok.
> 

Still need to read more.  I've been busy lately, but I've started making initial modifications for X11 already in the ui\native directory.


>>Thanks again for the wine suggestion.  That could be a very useful resource.
> 
> 
> Yep, Wine approach might work.
> I did some tests - it is close.
> 
> In fact Harmonia Win32 applications should work 'as is' under the Wine.
> 
> 

Actually I wasn't looking at using wine to run harmonia.  Wine source is useful to see how to interface with X and draw the widgets.  That was my main interest.  Wine makes use of XComposite, Xrender, and alpha blending techniques, so it's a good resource for an X programming howto.

I don't want to do a wine based port.  Nothing but pure X11 interests me! :-)

-JJR

Hi, I've spent a couple of hours tonight creating a basic stub port of
Harmonia.  I've simply copy/paste/hacked the win32 stuff until there is
basically nothing left - ie, I've just done the grunt work :)
My original idea was to use SDL as the targeted port - though I don't
know how well this will work, my concerns are with the clipboard primarily.
So, I've attached a 20K patch file that adds a GNU makefile, and some
SDL files that are no more than stubs.  The whole mess compiles but does
not link, a finddata function is missin and I don't know what is going on.

I hope that others may find this useful.  Also, any comments about using SDL as a backend are much appreciated.

Brad