www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Harmonia Porting

reply John Demme <me teqdruid.com> writes:
I've just started going through the Harmonia source (can't try it,
unfortunately, as I don't use Windows) and I've got a few notes that
would help porting.

It seems like you've been going for a relatively easy porting process,
but there are a few more steps you can take:
	-Create interfaces for all of the classes in harmonia.ui.native.win32*
	-Don't import harmonia.ui.native.win32* in anything outside of that
package.  Instead, for all of these create another file without the
win32 that has public imports.  For instance, create
harmonia.ui.native.application, and have it contain something like:
version (Windows) {
	public import harmonia.ui.native.win32application;
}
else
{
	static assert(0);
}

This way, when a port is made, one really only has to implement the
aforementioned interfaces, and modify some 4 files in ui.native to
import them in the linux version.

Documentation.  (You probably know about this one.) Since I've never
done any Windows GUI programming, I don't know what a lot of this stuff
is or does.  Should you create those interfaces, it's important to give
details as to what each method does.  Right now, many are almost direct
windows calls, but wouldn't be on a Linux port, so the exact behavior
must be noted.

On a non-technical note: the license.  In order for me to use Harmonia,
it's license would need to be GPL-compatible.  And of course if I can't
use it, I'm definately not going to contribute code. (But don't take
that to mean that if it is, I will.)  I'm not sure if your license is
GPL-compatible, but I would recommend simply choosing a license from
this list:
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
choosing one that's close, and noting that your are using this license.
It's much more simple for everyone else if you use a "standard" one.

Back to technical stuff: Unix guys: from the little bit of browsing I've
done through the native modules, it looks like a Unix port could either
use the plain and simple X11 libs, or GDK.  I'm not familiar with
either, however.  Does this sound about right?

That's it for me, for now.
John Demme
May 14 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hi, John, see inline:

"John Demme" <me teqdruid.com> wrote in message 
news:1116091945.19794.50.camel localhost.localdomain...

 I've just started going through the Harmonia source (can't try it,
 unfortunately, as I don't use Windows) and I've got a few notes that
 would help porting.

 It seems like you've been going for a relatively easy porting process,
 but there are a few more steps you can take:
 -Create interfaces for all of the classes in harmonia.ui.native.win32*


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.

I understand motivation but don't think that interfaces is an effective 
solution.
Interfaces are heavy a bit and they always needs some class instance....
If we will treat 'interface' as an API then I think it would be just enough 
to define/list
native functions in porting.txt file in the distribution.
I' ll try to write such file today.


 -Don't import harmonia.ui.native.win32* in anything outside of that
 package.  Instead, for all of these create another file without the
 win32 that has public imports.  For instance, create
 harmonia.ui.native.application, and have it contain something like:
 version (Windows) {
 public import harmonia.ui.native.win32application;
 }
 else
 {
 static assert(0);
 }

 This way, when a port is made, one really only has to implement the
 aforementioned interfaces, and modify some 4 files in ui.native to
 import them in the linux version.


Exactly, that was my intention too,

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.

So for porting it is just enough to update version sections in those six 
files.

Let me know if you think this is still the problem.


 Documentation.  (You probably know about this one.) Since I've never
 done any Windows GUI programming, I don't know what a lot of this stuff
 is or does.  Should you create those interfaces, it's important to give
 details as to what each method does.  Right now, many are almost direct
 windows calls, but wouldn't be on a Linux port, so the exact behavior
 must be noted.


Agreed.


 On a non-technical note: the license.  In order for me to use Harmonia,
 it's license would need to be GPL-compatible.  And of course if I can't
 use it, I'm definately not going to contribute code. (But don't take
 that to mean that if it is, I will.)  I'm not sure if your license is
 GPL-compatible, but I would recommend simply choosing a license from
 this list:
 http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
 choosing one that's close, and noting that your are using this license.
 It's much more simple for everyone else if you use a "standard" one.



which by itself is compatible with GPL.
If you think that it is not close enough then let me know, I'll update it.


 Back to technical stuff: Unix guys: from the little bit of browsing I've
 done through the native modules, it looks like a Unix port could either
 use the plain and simple X11 libs, or GDK.  I'm not familiar with
 either, however.  Does this sound about right?


As to my knowledge: Harmonia can use only X11 libs without any
additional layer like GDK.
Only one:
I am going to make a bridge to standard OS Shell dialogs like OpenFile, 
SaveFileAs
and SelectPrinter. These may require interaction with OS Shell.
But as a zero level porting these dialogs can be implemented in Harmonia 
using its own
Dialog facility and Phobos file objects.

As Harmonia does not use system widgets (like editbox, etc.)  then
I think porting could be made more or less flawlessly and compact.

FLTK (http://fltk.org) use the same approach and it was ported  on
UNIX/Linux (X11), Win32 and MacOS X.
I think that FLTK sources could be used as a manual for Harmonia native 
modules porting.

And of course in case of any problems with porting please let me know.

Andrew.
May 14 2005
next sibling parent reply John Demme <me teqdruid.com> writes:
On Sat, 2005-05-14 at 13:07 -0700, Andrew Fedoniouk wrote:

 Back to technical stuff: Unix guys: from the little bit of browsing I've
 done through the native modules, it looks like a Unix port could either
 use the plain and simple X11 libs, or GDK.  I'm not familiar with
 either, however.  Does this sound about right?


 
 As to my knowledge: Harmonia can use only X11 libs without any
 additional layer like GDK.


The only reason I mention GDK, is because I believe it makes things
easier, and look nicer.  It is, after all, the back end for GTK.


 Only one:
 I am going to make a bridge to standard OS Shell dialogs like OpenFile, 
 SaveFileAs
 and SelectPrinter. These may require interaction with OS Shell.
 But as a zero level porting these dialogs can be implemented in Harmonia 
 using its own
 Dialog facility and Phobos file objects.
 


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.

John Demme
May 14 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:1116103698.19794.81.camel localhost.localdomain...

 On Sat, 2005-05-14 at 13:07 -0700, Andrew Fedoniouk wrote:

 Back to technical stuff: Unix guys: from the little bit of browsing 
 I've
 done through the native modules, it looks like a Unix port could either
 use the plain and simple X11 libs, or GDK.  I'm not familiar with
 either, however.  Does this sound about right?


 As to my knowledge: Harmonia can use only X11 libs without any
 additional layer like GDK.


 The only reason I mention GDK, is because I believe it makes things
 easier, and look nicer.  It is, after all, the back end for GTK.


If GDK is something standard for all *x'es then why not? if it is easier...


 Only one:
 I am going to make a bridge to standard OS Shell dialogs like OpenFile,
 SaveFileAs
 and SelectPrinter. These may require interaction with OS Shell.
 But as a zero level porting these dialogs can be implemented in Harmonia
 using its own
 Dialog facility and Phobos file objects.


 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.


Probably, yes. Question is just about usability and user preferences.
In Windows such dialogs allow you to select stuff in e.g. Shell Name 
Extensions
but this seems so rarely used so we can drop this.

(Shell Name Extensions was one more bright idea trying to give
felicity-for-everybody-and-free-of-charge, but people didn't buy it.)
May 14 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Andrew Fedoniouk wrote:


The only reason I mention GDK, is because I believe it makes things
easier, and look nicer.  It is, after all, the back end for GTK.


 
 
 If GDK is something standard for all *x'es then why not? if it is easier...
 


It's not standard for all x's although it may be ported to the majority 
of them.  I don't think such a dependency is a good idea.  Of course, if 
someone is interested in attempting such a port, it can't hurt to try, 
correct?  The more the merrier:  Harmonia could use X11, opengl, GDK... :)

It would only be an adavantage to have several options.   For now, I 
think giving X11 a try should be a higher priority.



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.


 
 
 Probably, yes. Question is just about usability and user preferences.
 In Windows such dialogs allow you to select stuff in e.g. Shell Name 
 Extensions
 but this seems so rarely used so we can drop this.


True, but on unixes these file dialogs are too varied and unreliably 
disimilar... that is, there is no standard.  On Windows, on the other 
hand...

-JJR
May 14 2005
prev sibling parent reply Burton Radons <burton-radons smocky.com> writes:
John Demme wrote:


 On Sat, 2005-05-14 at 13:07 -0700, Andrew Fedoniouk wrote:
 

Back to technical stuff: Unix guys: from the little bit of browsing I've
done through the native modules, it looks like a Unix port could either
use the plain and simple X11 libs, or GDK.  I'm not familiar with
either, however.  Does this sound about right?


As to my knowledge: Harmonia can use only X11 libs without any
additional layer like GDK.


 
 The only reason I mention GDK, is because I believe it makes things
 easier, and look nicer.  It is, after all, the back end for GTK.
 
 

Only one:
I am going to make a bridge to standard OS Shell dialogs like OpenFile, 
SaveFileAs
and SelectPrinter. These may require interaction with OS Shell.
But as a zero level porting these dialogs can be implemented in Harmonia 
using its own
Dialog facility and Phobos file objects.


 
 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.

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.
May 14 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
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.

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.


 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.

-JJR
May 14 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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?
May 14 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Andrew Fedoniouk wrote:

<snip>


 

Back to technical stuff: Unix guys: from the little bit of browsing I've
done through the native modules, it looks like a Unix port could either
use the plain and simple X11 libs, or GDK.  I'm not familiar with
either, however.  Does this sound about right?


 
 
 As to my knowledge: Harmonia can use only X11 libs without any
 additional layer like GDK.
 Only one:
 I am going to make a bridge to standard OS Shell dialogs like OpenFile, 
 SaveFileAs
 and SelectPrinter. These may require interaction with OS Shell.
 But as a zero level porting these dialogs can be implemented in Harmonia 
 using its own
 Dialog facility and Phobos file objects.


If you do this bridge, be aware that it will make other ports more 
complicated on other platforms... because all equivalent high-level 
dialogs are located in GTK or Qt or whatever (on linux for example). 
This dependency is a pretty big one and acutely changes the original 
advantage of Harmonia and any discussion of forgoing interaction with 
GTK/GDK.


 As Harmonia does not use system widgets (like editbox, etc.)  then
 I think porting could be made more or less flawlessly and compact.


I liked the idea of Harmonia because its premise had no reliance on 
system widgets.


 FLTK (http://fltk.org) use the same approach and it was ported  on
 UNIX/Linux (X11), Win32 and MacOS X.
 I think that FLTK sources could be used as a manual for Harmonia native 
 modules porting.


True, FLTK is a good example of a project with similar goals.  It may 
very well be a good resource.

I'm working on other projects right now, but I'd like to see this one 
work too.  I'll see what I can do.

-John
May 14 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 If you do this bridge, be aware that it will make other ports more 
 complicated on other platforms... because all equivalent high-level 
 dialogs are located in GTK or Qt or whatever (on linux for example). This 
 dependency is a pretty big one and acutely changes the original advantage 
 of Harmonia and any discussion of forgoing interaction with GTK/GDK.


I any case it will be just standalone functions like
Application.selectFile( string defaultFolderPath, fileTypes, flags )
this funtion on win will use nativeSelectFile and on other
platforms it could be implemented in Harmonia as modal Dialog.

The idea is simple: Harmonia should allow to write GUI even on
devices without OS in common sense.
Theoretically if we will have a kernel implementation
on some device then Harmonia can work there.
Market of smart devices is here... (idea for Walter).


 As Harmonia does not use system widgets (like editbox, etc.)  then
 I think porting could be made more or less flawlessly and compact.


 I liked the idea of Harmonia because its premise had no reliance on system 
 widgets.


Yes and there is huge class of tasks which does not require system
widgets. Even such things as IDEs in genereal do not strongly require them.
E.g. IDEs in pure Java all made without them.
Eclipse is an exception but they were forced to use SWT because
Sun seems like not interested in Java GUI at all.

Even Microsoft in Avalon is dropping system widgets in favour
of managed ones written from ground up (WinForms.Net is dying) and XAML.

I think that upcoming Harmonia.RichTextBox can be used as a
source code editor with not only syntax highlighting but with also
inline documentation in WYSIWYG (dream).


 FLTK (http://fltk.org) use the same approach and it was ported  on
 UNIX/Linux (X11), Win32 and MacOS X.
 I think that FLTK sources could be used as a manual for Harmonia native 
 modules porting.


 True, FLTK is a good example of a project with similar goals.  It may very 
 well be a good resource.

 I'm working on other projects right now, but I'd like to see this one work 
 too.  I'll see what I can do.

 -John
May 14 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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
May 17 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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.
May 17 2005
parent John Reimer <brk_6502 yahoo.com> writes:
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! ;-)
May 17 2005
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
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
May 21 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
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
May 21 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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
May 27 2005
parent John Reimer <brk_6502 yahoo.com> writes:
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
May 28 2005
prev sibling parent brad beveridge <brad nowhere.com> writes:
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
May 29 2005
prev sibling parent John Reimer <brk_6502 yahoo.com> writes:
John Demme wrote:
<snip>


 Back to technical stuff: Unix guys: from the little bit of browsing I've
 done through the native modules, it looks like a Unix port could either
 use the plain and simple X11 libs, or GDK.  I'm not familiar with
 either, however.  Does this sound about right?


It would be best to use X11 directly.  Harmonia provides the actual 
widget drawing.  This further allows for common look/feel between it and 
the windows port.  GDK is too high level; and as common as GDK/GTK is, 
it is not available everywhere.  I think the idea of harmonia is to keep 
the library as simple and independent of platform as possible.

-JJR
May 14 2005