FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

query about inconsistency, with ideas

 
Post new topic   Reply to topic     Forum Index -> gtkD
View previous topic :: View next topic  
Author Message
bob



Joined: 22 Jan 2007
Posts: 5
Location: Indiana, USA

PostPosted: Mon Jan 22, 2007 4:53 pm    Post subject: query about inconsistency, with ideas Reply with quote

just a quick question. should Duit.main()... Duit... really be the main loop class? this breaks consistency with pretty much every interface there is.

Code:
C: gtk_main();
C++: Gtk::main::run();
PHP: gtk::main();
Perl: Gtk->main;
Python: Gtk.main();
Ruby: Gtk::main();


my suggestion is that the actual class be renamed (read fixed).


Last edited by bob on Tue Jan 23, 2007 1:31 am; edited 1 time in total
Back to top
View user's profile Send private message
bob



Joined: 22 Jan 2007
Posts: 5
Location: Indiana, USA

PostPosted: Tue Jan 23, 2007 1:30 am    Post subject: Reply with quote

not to be rude, i respect the work put into this project, but to be honest i am actually quite turned off by this class structure for gtk2. the inconsistencies between established protocols and what you guys are making up for D are outstanding. another major problem i foresee is overlapping classes with how generic things have been setup. who knows when seeing "Window w" if it refers to Gtk2 or what. and the alternative reference "gtk.Window.Window w" is too ugly to be mentioned.

it almost feels that because this is so new, everyone is trying to get their own flavour in so they will be remembered - and that alone could cause D to fail. also a the capitalization in things like "import gtk.Window" even goes against the spec on the digital mars site.

do not get me wrong! i really want to see this project done right, and i really want this to become as usable as the C interface or gtkmm. however we/it needs major guidance atm.

(btw i agree on the name gtkd with lowercase d.)

Code:
GtkWidget *w;
w = gtk_window_new(GTK_WINDOW_TOPLEVEL);


Code:
$w = new GtkWindow(Gtk::WINDOW_TOPLEVEL);


Code:
Window w = new Window("the window title"); // WHAT?


how it is
Code:
import std.stdio;

import gtk.Duit;
import gtk.Window;

//. super basic without any cares about proper.

int main(char[][] argv) {

   Duit.init(argv);

   Window w = new Window("The Window Title");
   w.showAll();
   
   Duit.main();

   return 0;
}


how it probably should look instead.
Code:
import std.stdio;

//. this being everything, the equiv to #include <gtk/gtk.h>
import gtk.gtk;

//. super basic without any cares about proper.

int main(char[][] argv) {

   gtk.init(argv);

   gtk.Window w = new gtk.Window(gtk.WINDOW_TOPLEVEL);
   w.setTitle("The Window Title");
   w.showAll();
   
   gtk.main();

   return 0;
}


even these would make at least a little sense with sustainability regards.
Code:
gtkWindow w = new gtkWindow();
gtk.gtkWindow w = new gtk.gtkWindow();

GTK_WINDOW_TOPLEVEL
gtk.gtkWindowToplevel // not so good as other two,

_________________
- b.
Back to top
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Tue Jan 23, 2007 9:57 am    Post subject: Reply with quote

bob wrote:
... i am actually quite turned off by this class structure for gtk2.

Thank you for these ideas.
I'm not going to rush to reply, I'll take it into consideration.

Don't hesitate to post more, let us see your perspective.
It's important the Duit (or gtkd) get to a final version soon and we don't want it to be the wrong one...

Ant
Back to top
View user's profile Send private message
hauptmech



Joined: 14 Jan 2007
Posts: 20
Location: Wellington, NZ

PostPosted: Tue Jan 23, 2007 1:45 pm    Post subject: Reply with quote

(keep in consideration I have little experience with gtk+)

Having all the classes under a single namespace makes sense.
Having that namespace be "gtk" I like.
Does D have any magic that will let you unify all the modules under a single namespace?

re: Window vs GtkWindow:
I think "Window" is better. It's easy to us "gtk.Window" if you have namespace collisions.

I really respect the work that went into the present wrapper. That said, there are 3 flavors that I think people will want...

1. A binding.

2. A direct OOP implementation of what the folks at gtk+ tried to do lacking a portable,bindable OOP language. Programmers already familiar with gtk+ will be able to write apps without reading a bit of documentation...

3. A D Gui toolkit (using gtk+ libs) that has it's own parallel object structure that does things cleaner/better where it can. New and old gtk+ programmers alike will have to do a bit of learning.

Without implying any judgement; I think #3 is where duit is heading. Here overloading the constructor to set the title and assume TOP_LEVEL is fine. If you never heard of it; no worries... The old way works as well.

I think that if duit can be all three flavors at once it will do the best. The binding seems trivial, but having it usable by programmers that don't want to add D's object baggage to their program is important. One of D's strengths is keeping the low-level available if you need it. (I write hard realtime control software for robots... I need it. )

The direct implementation of gtk's OOP structure in D... It will be important to do this as closely as D can so that existing gtk programmers can just write code and enjoy using the language. At this level I think it's fine to add overloaded functions and operators to extend the gtk api a bit. It's always a problem if the function you expect from gtk is missing... Not so much a problem if you find there is an extension to gtk that you didn't know about.

The "D way of GUI programming" is a great goal for any library... but I think that if duit does that at the expense of being a good gtk wrapper then it's silly to call it a gtk wrapper.
_________________
-hauptmech
Back to top
View user's profile Send private message
bob



Joined: 22 Jan 2007
Posts: 5
Location: Indiana, USA

PostPosted: Tue Jan 23, 2007 4:12 pm    Post subject: Reply with quote

i am really glad to see that the only response i got was not "no. shut up." i was kind of worried that there would be too much pride and stuff getting in the way of standard acceptance.

mind you this is a really, really simple example compared to gtk, but here is what i was working on in my playing. it is an example of a library type interface.

bobapp.d
Code:
import std.stdio;

import bob = bob.main;

int main(char[][] argv) {

   bob.printmsg();
   writef(
      "?d:OMG\n?d:WTF\n?d:BBQ\n",
      bob.OMG,
      bob.WTF,
      bob.BBQ
   );

   return 0;
}


the library
Code:
module bob.main;

import std.stdio;

enum { OMG, WTF, BBQ }

//. my stupid function for sake of demonstration.
void printmsg() {
   writef("bob is a winner.\n");
}


Makefile
Code:
all:
   dmd bob/main.d -odobj -op -c
   rm bob/libbob.a -f
   ar rcsP bob/libbob.a  obj/bob/main.o
   
   dmd bobapp.d -release -O -I. -L-lpthread -L-lm -L-lphobos -L-Lbob -L-lbob


result
Code:
//. bob@elenothar [testing]$ ./importing
bob is a winner.
0:OMG
1:WTF
2:BBQ


this example is probably too simplistic to apply to the full gtkd project, but i began playing around doing a glib and gtk library like this before i was told about Duit. with enough love and time we could easily generate the kind of end user code like

Code:
gtk.Window w = new gtk.Window(gtk.WINDOW_TOPLEVEL)


and it would be worth it, for sure.
_________________
- b.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Jan 23, 2007 5:39 pm    Post subject: Reply with quote

hauptmech wrote:
(keep in consideration I have little experience with gtk+)

Having all the classes under a single namespace makes sense.
Having that namespace be "gtk" I like.
Does D have any magic that will let you unify all the modules under a single namespace?


D namespaces are in the form of modules (filenames) and packages (directories); so yes that's easily feasible, and it's not even magic. Smile

See my other thread about why I think calling the DUIT/gtkd namespace "gtk" is wrong ( summary: gtk should represent the original C function set, not the wrapper class). A couple of other points follow:

DUIT/gtkd is a thin wrapper, yet, as a OO framework, it won't be exacly equivalent to C gtk. If a programmer needs that, he or she may use the actual gtk C functions themselves from D. Otherwise, it looks to me that the larning curve for DUIT should be quite minimal for anyone familiar with GTK+.

Furthermore, I assume we are talking about each individual namespace in the whole gtk scheme: gdk, atk, gthread, gobject. Each of these should retain their specific namespace even in the OO form (as it currently does in DUIT). That said, I don't like most of the gtk name forms (gtk, glib, gdk, atk, etc) because these names are quite meaningless (I usually detest meaningless names... it's one point I tolerate in DUIT for the cause of practicality) . But if we were to change those names to something clear and readable for DUIT/D, than I suppose we would succeed in alienating all the potential D gtk developers out there. Razz

hauptmech wrote:

re: Window vs GtkWindow:
I think "Window" is better. It's easy to us "gtk.Window" if you have namespace collisions.


I agree. There is really no need to go back to the old naming scheme of C. C developers needed to name project functions with gtk attached because it's namespace remains quite global and thus limited. Razz

hauptmech wrote:

I really respect the work that went into the present wrapper. That said, there are 3 flavors that I think people will want...

1. A binding.


A binding is already present in the form duit/lib package which lists all gtk related functions for dynamic loading; these can be used independently of DUIT. A static set of the same gtk bindings are available in the bindings project and the BCD header converter projects. Of course these become more of a task because you have to manually add all required C static libs to the final build process.

hauptmech wrote:

2. A direct OOP implementation of what the folks at gtk+ tried to do lacking a portable,bindable OOP language. Programmers already familiar with gtk+ will be able to write apps without reading a bit of documentation...


I'm no so sure the reason was that gtk+ people lacked such a language. I believe they chose C because they felt it was the best way to get a GUI interface supported across multiple platforms and multiple languages. DUIT/gtkd is a pretty thin wrapper around gtk+, so almost achieves the #2. But inevitably a wrapper is going to have individual design preferences.

hauptmech wrote:

3. A D Gui toolkit (using gtk+ libs) that has it's own parallel object structure that does things cleaner/better where it can. New and old gtk+ programmers alike will have to do a bit of learning.

Without implying any judgement; I think #3 is where duit is heading. Here overloading the constructor to set the title and assume TOP_LEVEL is fine. If you never heard of it; no worries... The old way works as well.


I think DUIT/gtkd has the potential to evolve in this direction. But there might be a limit in usefulness in going too far this way. The more one strays from the complex gtk base, the more subtle the learning curve. Bugs also like to torment this enviroment. I think DUIT has achieved a happy medium between #2 and #3 and, as far as gtk support goes, is best not to stray too far. Gtk is already very comprehensive in itself.

That said, the advantages of departing from pure GTK+ functionality are great, and I really don't mind any "ease-of-use" features that DUIT adds to the current GTK+ mess. Yes, mess... as a C library GTK+ is not what you call developer friendly. I believe that being able to avoid things like GTK pointer types in function arguments and such are good examples of where the D wrapper can shine over C style (D can use reference types and inout parameters instead where necessary). Naming convention of D types and classes are also an important improvement in readability.

hauptmech wrote:

I think that if duit can be all three flavors at once it will do the best. The binding seems trivial, but having it usable by programmers that don't want to add D's object baggage to their program is important. One of D's strengths is keeping the low-level available if you need it. (I write hard realtime control software for robots... I need it. )


Agreed. And those bindings are indeed available.


hauptmech wrote:

The direct implementation of gtk's OOP structure in D... It will be important to do this as closely as D can so that existing gtk programmers can just write code and enjoy using the language. At this level I think it's fine to add overloaded functions and operators to extend the gtk api a bit. It's always a problem if the function you expect from gtk is missing... Not so much a problem if you find there is an extension to gtk that you didn't know about.


I'm not sure, but I think you are talking about an even thinner layer than DUIT (no D OOP used). In which case, I can't agree that this is optimal since I don't really like low-level C gtk. But such is indeed possible even though I think you may as well just use C functions directly.

There are methods of merely renaming these C functions with aliased D functions and namespace to produce the ultimate in thinly wrapped. I did it with glfw. You get D style function naming with the original C function arguments. Some might prefer that, and I doubt it would be hard to automate the task of conversion.

hauptmech wrote:

The "D way of GUI programming" is a great goal for any library... but I think that if duit does that at the expense of being a good gtk wrapper then it's silly to call it a gtk wrapper.


Any wrapper is going to be a subjective affair. Ant has already done a fairly thin OOP wrap of GTK. I think he's done a good job. My opinion (I guess I have a lot of opinions today Razz ) is that it might be improved, but it is a fine balance on which way it goes.

If there is a preference for other types of wrappers, I think its a fairly simple affair to produce those other types with customized automatic conversion tools. The wrapper tools in Ant's DUIT project certainly provide an excellent starting point. Some modification of those and appropriate namespace and module names, combined with function aliasing... alternate styles of Gtk+ bindings may be produced.

Thanks for your cotnributions, hauptmech. Hope you didn't mind mine. Smile
Back to top
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Tue Jan 23, 2007 6:47 pm    Post subject: Reply with quote

bob wrote:

Code:
Window w = new Window("the window title"); // WHAT?



to clarify all these versions are valid on Duit:

Code:



//version=plain;
//version=plainOO;
version=Duit;

version(Duit)
{
   
   private import gtk.MainWindow;
   private import gtk.Duit;
   
   int main(char[][] args)
   {
      Duit.init(args);
      MainWindow window = new MainWindow("");
      window.show();
      Duit.main();
      
      return 0;
   }
}

version(plain)
{
   private import lib.gtk;
   private import gtk.gtktypes;

   int main( char[][] args )
   {
      GtkWidget *window;
      
      gtk_init(null, null);   // todo: needs to convert args
      
      window = gtk_window_new (GtkWindowType.TOPLEVEL);
      gtk_widget_show  (window);
      
      gtk_main ();
      
      return 0;
   }
}

version(plainOO)
{

   private import gtk.Window;
   private import gtk.Duit;
   private import gtk.gtktypes;

   int main(char[][] args)
   {
      Duit.init(args);
      Window window = new Window(GtkWindowType.TOPLEVEL);
      window.show();
      Duit.main();
      
      return 0;
   }
   
}



Ant
Back to top
View user's profile Send private message
bob



Joined: 22 Jan 2007
Posts: 5
Location: Indiana, USA

PostPosted: Tue Jan 23, 2007 7:10 pm    Post subject: Reply with quote

JJR wrote:
See my other thread about why I think calling the DUIT/gtkd namespace "gtk" is wrong


Even if it is, standards should not be broken. look at the first post in this. no matter what language is picked up you can write the app without using a function reference if you know the C one. I believe that is how it should be, D included. Taking gtkmm for example, you dont have to use Gtkmm::Window.

I (and most programmers i know) consider the C interface to be "the" GTK2, and all other languages are merely translating syntax. Contextual disfluencies will just make it a pain to learn for experienced toolkit users of another language.
_________________
- b.
Back to top
View user's profile Send private message
FunkyM



Joined: 26 Apr 2006
Posts: 5
Location: Germany

PostPosted: Thu Mar 15, 2007 12:50 pm    Post subject: Reply with quote

A few points I don't like about gtkD:

- API is generated from (always-lacks-behind-sources) documentation
- I can not find out which GTK+ version this binding maps to exactly nor is there a clear versioning scheme
- GtkD.init()/Gtk.init(), cairoLib/Cairo, gtk.gtktypes, gtk.GtkD are things that pollute the API in my opinion (sometimes relate to D's module system)
- Not sure the GObject model is applied into the binding API (classes, interfaces, ...)
- Unrequired API differences from already established OOP-ified GTK+ bindings of other languages (Why reinvent? carioLib.Cairo vs Cairo.Context, ...)
- It is missing new API additions such as GtkStatusIcon for me
- I want versioned shared libraries by default on Linux ;)
- Requires this compD tool which should be removed
- Arguments and return types don't map into a OOP structure, rather assemble the old C type names
- Current bindings are incomplete, segfault easily and are a tidbit "chaotic" aka. "let's make it compile asap." ;)
- gstreamerD should not be a part of gtkD, it should rather use the provided wrapper/tools to be converted as an independent project

Don't get me wrong, really great work on this huge thing and it's prolly more than you need for serious GTK+ application development already.
I was able to convert some alphablending/composite environment GTK#/Cairo code in a few minutes to use gtkD so it's really good.

My comments are purely for constructive improvements, ideas for the future direction of GNOME-related bindings and certainly need discussion.

I am thinking of some improvements:
- Mono GAPI2 like C source to D code binding generation utilizing GObject Model features (Very nice! C to XML to D Bindings) usable for different binding projects
- Cross-Platform Library Improvements (Dynamic on Win, Handled by linking step on Linux; is a dynamic library loader the best solution?)
- API-based on already existing bindings (Mono GNOME API rocks and I it would make porting some C# applications easier, alternatively gtkmm)
- Set requirements to be accepted as official binding
- Add abstraction to be Phobos/Tango compatible
- Always define the API version mapping from binding to real library
- Work with GDC in the first place

The aim is to provide an automatically generated OOP binding which closely applies to the Mono GNOME APIs and provides enchanced GObject features.

Such an approach might have a better chance to be accepted as the official D bindings as gtkD does not seem to be really accepted due to various issues.

If any cross-platform D native GUI toolkit is done, it might make use of this gtkD OOP backend on appropriate platforms aswell.

Currently I am trying to make a full autotools based gtkD project skeleton if anyone is interested.
Back to top
View user's profile Send private message
kaarna



Joined: 03 Apr 2006
Posts: 92
Location: Finland

PostPosted: Fri Mar 16, 2007 8:02 am    Post subject: Reply with quote

Just to note, that I haven't really used gtkD that much yet. But I just made the gstreamerD bindings, so I thought that I'd still reply.

I agree with some of this critique. And for gtkD to really be good, it should change some things. It's a really good point that gtkD should be similar to existing OO bindings that gtk+ already has.

FunkyM wrote:

- API is generated from (always-lacks-behind-sources) documentation


Hmm. I can only say that for gstreamerD it seems to not be a problem. The documentation is build from the GStreamer source code, so it is propably up-to-date. Ofcourse this might be a problem for GTK+, because it's a larger project...

FunkyM wrote:

- Unrequired API differences from already established OOP-ified GTK+ bindings of other languages (Why reinvent? carioLib.Cairo vs Cairo.Context, ...)


Yes. This is the biggest problem for gtkD, in my opinion. I think Ant doesn't want to look at other projects, because he thinks it would hurt his licencing options. But I think that just looking at their code, and using their established standards is necessary. LGPL isn't that bad a licence. I don't think that other licences are necessary, and therefore it should be OK to look and take code from other LGPL bindings for GTK+.

FunkyM wrote:

- Requires this compD tool which should be removed


Yes. It should be removed. But I don't think that GNU autotools is a good option either. At the moment it is really difficult to start using gtkD, as you'll have to do a svn checkout from the dool project just for compd.

FunkyM wrote:

- gstreamerD should not be a part of gtkD, it should rather use the provided wrapper/tools to be converted as an independent project


Currently gstreamerD is compiled into a separate library. It is just resting inside the gtkD subversion tree. You can choose to ignore it. But it might be better for longer term to make it into it's own project... I'm not sure.

FunkyM wrote:

I am thinking of some improvements:
- Mono GAPI2 like C source to D code binding generation utilizing GObject Model features (Very nice! C to XML to D Bindings) usable for different binding projects
- API-based on already existing bindings (Mono GNOME API rocks and I it would make porting some C# applications easier, alternatively gtkmm)
- Set requirements to be accepted as official binding


You've gotten me interested. I'll take a look at the mono bindings. They seem like a good standard.

FunkyM wrote:

- Always define the API version mapping from binding to real library
- Work with GDC in the first place


GDC support is really important. That's what most people will be using in the real GTK+/Linux world.

FunkyM wrote:

Currently I am trying to make a full autotools based gtkD project skeleton if anyone is interested.


I'm interested, although I'm not really a fan of the autotools, as they seem really complicated and full of wierd scripting. But they might ease packaging for different distribution...

I personally don't have the time to create gtkD bindings. I'm just writing an app using them. And I just hope that gtkD goes to the "right" direction.

One thing is that enums propably shouldn't be in gtkc.gtktypes; A pure OO gtkD program shouldn't need to have import gtkc.gtktypes in it.
I don't know where they should be, but it might be a good idea to have unnamed enums that exactly map to the C one's like GTK_WINDOW_TOPLEVEL in gtkc.gtkc. And then have gtkD named enums like GtkWindowType.TOPLEVEL in gtk.gtk or what ever would be the appropriate case. Or then the gtkD enums should be unnamed and just be like gtk.WINDOW_TOPLEVEL like in many other bindings projects, so that it would be more standards compliant.
Just a thought...
Back to top
View user's profile Send private message AIM Address MSN Messenger
FunkyM



Joined: 26 Apr 2006
Posts: 5
Location: Germany

PostPosted: Sat Mar 17, 2007 12:02 pm    Post subject: Reply with quote

satelliittipupu wrote:
FunkyM wrote:

- Unrequired API differences from already established OOP-ified GTK+ bindings of other languages (Why reinvent? carioLib.Cairo vs Cairo.Context, ...)


Yes. This is the biggest problem for gtkD, in my opinion. I think Ant doesn't want to look at other projects, because he thinks it would hurt his licencing options. But I think that just looking at their code, and using their established standards is necessary. LGPL isn't that bad a licence. I don't think that other licences are necessary, and therefore it should be OK to look and take code from other LGPL bindings for GTK+.


Both are LGPL? However, looking at all the other available bindings API's, I don't think it matters here.

satelliittipupu wrote:
FunkyM wrote:

- Requires this compD tool which should be removed


Yes. It should be removed. But I don't think that GNU autotools is a good option either. At the moment it is really difficult to start using gtkD, as you'll have to do a svn checkout from the dool project just for compd.


GNU autotools is widely spread and accepted. It is certainly not the best possible toolset for D, however there is none which can compete yet and allow fast adoption/migration by people not used to D. Mono applications are bundled using autotools aswell. Alternatively, even a simple Makefile to compile gtkD which builds some "rebuild" tool and uses it to compile is better than the current solution.

satelliittipupu wrote:
FunkyM wrote:

- gstreamerD should not be a part of gtkD, it should rather use the provided wrapper/tools to be converted as an independent project


Currently gstreamerD is compiled into a separate library. It is just resting inside the gtkD subversion tree. You can choose to ignore it. But it might be better for longer term to make it into it's own project... I'm not sure.


Well, it's not that fundamentally important for now whether to bundle or not as long as the libraries are seperate.

satelliittipupu wrote:
FunkyM wrote:

Currently I am trying to make a full autotools based gtkD project skeleton if anyone is interested.


I'm interested, although I'm not really a fan of the autotools, as they seem really complicated and full of wierd scripting. But they might ease packaging for different distribution...


Neither am I, however it directly pleases developers, translators, maintainers, users and packagers, is the most used (powerful) toolset and it would ease transition for new D rookies (coming from GTK+/GNOME application grounds) significantly. Sure, once a better approach is possible it should be used instead of the "mass scripting". If you like to get SVN access or in touch, my nickname is psp250 on the #d IRC channel on irc.freenode.org.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> gtkD All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group