Some demos need to be rewritten or completed

I'm not comfortable with either gstreamer, sourceview or gda inside gtkD. I haven't touched them, but I haven't done much to support them either. In fact, automatic wrapping of gstreamer is now disabled by default (it did seem to require a lot of hand tuning to get it to compile). Personally, I don't think these projects belong in gtkD. Moving their directories to src/ shouldn't be much of a problem, as output directories are defined in the APILookup*.txt files. I'll put that on my TODO list if requested.

demos/gtk/DrawRect will now segfault from r348 onwards. This is expected behaviour due to the changes from ticket #3. It's possible to avoid this by enabling exceptions (not recommended for now).

Bah, I accidently deleted my first post for this ticket. Here it is again:

I'm wondering if gda, gl, gcsv, and gstreamer demos even belong in the demos folder until there is a clearly defined way to install and test them based on their bindings. I suppose the scripts are supposed to just work?

This is the problem with using compd scripts that don't tell you how or where a private project needs to put these bindings/wrappers to use these extended features (or even gtkd for that matter). This means there effectively is no protocol for using gtkd, gstreamer, or whatever in a project. compd was originally intended for operation with specifically leds, meaning leds was the only system that had structure for use of gtkd.

Since gda, gl, gcsv, and gstreamer are "addons" to gtkd, I think a reoorganization of them is in order... not quite sure how to do this right now, but the srcgda,srcgstreamer, etc should be moved or renamed or both... directories in trunk are frankly hideous, confusing, and distracting. One "suggested" organization is shown in branches/experimental/alternate1.

There are likely other options for these. But, at the very least, I don't think they should be cluttering the gtkd direcotry the way they are. If the idea is to integrate them with gtkd, then maybe they should be placed in the same directory as gtkd/src. Not that I think they belong there, I just think we need to make a firm decision: add them or move them.

Thoughts?

Sorry that this post is out of chronological order.

In answer to PSE, I will look into getting DrawRect? working, as well as some of the others. The gstreamer demos (also sourceview and gda) should be removed or moved to another directory. If we decide to take gstreamer and friends out, the demos can go with them.

From the next wrap following r361 onwards, it'll not be necessary to import typing information anymore (ticket #6). All "private import xxx.xxxtypes" should be removed from the demos.

I mostly like what I see in alternate1 branch. srcgstreamer was always hideous, but it was made according to model set by srcgl. The idea originally was that that way they were separate libraries. With dsss it's not really an issue, as everything seems to be separate libs now: gtk, gdk, pango etc. are all separate libs now, with dsss. Right? (I have to admit I haven't tested gtkD in the last month. I'm just interpreting the latest changes... Might be wrong here...)

But one thing I don't like about it is putting everything under the package (or module or whatever) gtkd. It would be better IMHO to just have like: import gtk.all; //A module to import all. ?? import gtk.Window; import cairo.all; import cairo.Context; import gstreamer.Element; import pango.PgLayout?; import glgdk.GLContext; //And if we must: import gtkc.window; //Or something like this... I don't remember the internals of the C version.

But this is a matter of taste, I guess. Anyway, I'd feel awkward writing: import gtkd.cairo.Context; import gtkd.gstreamer.Element; as they are not really part of GTK+, but separate projects.

If people want, I could start a separate project for gstreamerD on DSource, but I'd rather not. It's really closely tied to the wrapper. (And gstreamerD needs gtkD to work at all.) I guess it would be better to just move the extras to an extra dir. Also on the wrapper side there could be /wrap/extra/ or something similar containing the APIlookup stuff for them.

One idea to make wrap better: Make it a GUI tool using gtkD! Add options on what to wrap as GUI buttons etc.

What do you think?

Don't know about the alternate1 branch, but in trunk it is not necessary to prepend gtkd. to import any modules. In fact, it is not possible to do so.

I do agree gstreamerD is too tied to gtkD at this time, and particularly, to the wrapper, so it'd be problematic to start a separate project for it. I still feel gstreamerD does not belong in gtkD, though.

Agreed. alternate1 was my experiment with improving the directory structure of gtkd. It doesn't really work for the reason you mentioned... adding the gtkd prefix is too overwhelming. In fact, I already started making yet another alternative structure, but I haven't committed it yet because in order to make any new directory structure useful, the wrapper must be able to produce the output. That isn't as easy as I thought because some of the wrapper code was not designed for extreme flexibility.

Nevertheless, the next version of alternate removes all gtkd namespace prefixes and adopts the orignal flatter namespace style. I still want to change away from using a gtkc directory, though... I think gtkc/gtktypes and friends doesn't look very nice at all. Instead I've chosen to make each directory contain it's own c subdirectory like so:

gtk/c/types.d
gtk/c/functions.d
gtk/AboutDialog.d
etc..

atk/c/types.d
atk/c/functions.d
atk/Action.d
etc...

and the same idea for each of glib, gobject, and the rest. The only problem is finding a place for Loader.d. One possibility was to add a new directory called gtkd

gtkd/Loader.d
gtkd/all.d

and also use that directory to create a way to import all the separate sections of gtk like so:

gtkd/gtk.d  (this gtk will import all objects of the gtk/* package)
gtkd/atk.d  (this atk will import all objects of the atk/* package)

and so on...

This seems to be quite logically organized... of course it's not perfect, but I think something like that could work. It actually changes very little of the current packaging. The only problem is adding the c directories locally to each package makes for some difficulty in reprogramming the wrapper package. That will be a little more challenging.

Concerning making the wrapper a GUI tool... I completely agree. That would be great fun (if not time consuming). I also wish we could clean the wrapper code up and document it better in the process. Coding is very slow and methodical for me... I'm really not that fast so I love it when code is clean and well organized. It's probably a good think I don't make my living as a programmer. :)

NOTE: this is a discussion about package namespace reorganization in gtkd (this refers to the alternate1 branch, not TRUNK... yet :) ).

Hmm... I just read over Kaarna's suggestions again about organization of module namespace. He points out that he doesn't think the separate packages (atk, pango, gtk, cairo etc) should go under one heading like gtkd.cairo.Context (last demonstrated in the alternate1 branch). His argument is that packages like cairo are actually not part of gtk+, and thus the package namespace should not treat them as part of gtkd. Realistically, the argument that supports this package scheme is that gtkD is useless without these dependencies: gtkD is a project that wraps all these gtk package dependencies. So they really are not independent. So I would say the imbalance of putting the module namesapce in gtkd is more due to using the name "gtkd" for a D project that necessarily wraps much more than gtk+ itself. (I don't exactly like the name, but we've settled on it os that's that).

But for alternate1, I'm going to take this critique seriosuly and see how I can reorganize so that all packages don't end up under a gtkd namespace. If we are to indeed treat Cairo, atk, glib, etc as distinct entities then I'll see what kind of package namespace accomodates that train of thought.

I actually was looking at tango.group.* and started to like that system... but it may be overkill for gtkd. Hmmm.... although the choice could be between "import gtk.all" or "import gtk.group"... for some reason I have distaste for doing the "all" method. I'll see how it works.

Update: I've managed to make a shell script that converts current trunk wrapper output to my experimental alternate naming convention (had fun learning "find", "sed" and lots of regular expressions :)). This will make experimentation fairly easy without having to customize the wrapper.

I was surprised at how much automation can be done by shell scripts alone... probably some enterprising individual could make the gtkd process fully automated via shell scripts alone (scary thought, though).

BUT... I should get back to demo fixes and stop fooling around with "experimental" for now. Apologies!

Hi,

I'm really into using gtkd right now, but it's hard to make code work...

However, playing around (and exploring) the prerelease-9, I made (among other things ;D) a working drawrect example.

I'm attaching it as a file (I used dsss and the example dsss.conf file for compilation). (Is this the right place for that?)

Cheers, Unarmed aka TITiAN

* keywords changed from demos null constructor to demos null constructor working drawrect. * type changed from task to enhancement. * summary changed from Some demos need to be rewritten or completed. to a working drawrect demo.

Sorry.

a working drawrect example

This looks like something the DrawRect? demo was supposed to do. svn r527 adds the one you attached.

I've fixed the demos and intend to commit to svn tonight. This also includes how they are built, as well as including gstreamer in the master dsss.conf. I've tested an entire run through of the main libs and demos on both Windows and Linux.

Fixed in r535.