Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional gtk4 update #347

Open
wants to merge 16 commits into
base: gtk4
Choose a base branch
from
Open

Conversation

KonstantIMP
Copy link
Contributor

With this commit I have made some changes which should improve GtkD usage experience.

First of all I want to say that compiletime link of gtk and other G-type libraries is useless. On unix based machines we always have dynamic libraries(or can download it via our packet manager) and so don't need static linkage in general. If we talk about Windows computers - it is a bit more easier to download .dll files from MSYS or like this than compile it yourself. GTK applications becomes more popular, it means that using of dynamic libraries is better because this way uses less memory: (some shared libraries)*1 < (some apps with staticly linked libraries)*n. I made some changes because think that it is truth.

  1. The libraries are separated now. You can connect only one of them and forget about other. For example, you can import just GLib without GUI support(gtk widgets, gsk renderer and etc.).
  2. Linker class is in linker package now. It is not a part of Gtk, Glib or like this, so it should have different module path. Now it is gtk-d:linker
  3. Update examples. Gtk api was changed from 3 version. Some examples was fixed
  4. Work with libraries: add gtk4 wrap for gtksourceview5, connect libsoup, libshumate and libadwaita(thank @WebFreak001), temporary remove gstreamer - it has not been ported to gtk4 yet
  5. Also update scripts for docs generation
  6. Remove all build methods except dub. build everything you want with: dub build gtk-d:[module name]

Additional info: because gtkd.Loader was replaced by linker.Loader there are some changes in gir-to-d. I forked it and replaced wrap/ link with my repo

KonstantIMP added 13 commits January 16, 2022 12:06
* Remove useless gtkd.Paths
* Replace gtkd.Linker with linker.Linker because this class is not part
  of gtk and should have own package
* Add LinkException - only for link errors
* All libraries are separeted now. It means that you shouldn't have all
  libraries installed on your computer. If you need just gtk you don't
need to install sourceview, libsoup and other
It should decrease number of dll files for windows projects
not supported by official version
* gtkd.Linker was replaced with linker.Linker
* Was removed useless isLoaded(string []). It always calls
  isLoaded(string) just with the first element. So it was fixed in
gir-to-d
Everything can be compiled by dub
So makefile was removed
Copy link

@WebFreak001 WebFreak001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • maybe it would be better to leave broken examples existing? Quite a lot of interesting stuff has been removed, that might come back later
  • accidentally committed binary file demos/shumate/simpleMap/Map

addOnDraw(&drawCallback);
setDrawFunc ((area, cairo, w, h, data) {
(cast(Clock)data).drawCallback (new Context (cairo));
}, cast(void *)this, null);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing D wrapper of setDrawFunc to transfer context scope? (could access this in callback immediately then and not do the unsafe void* casts to this)

Should also probably not call GC (new Context) inside a draw function and rather use something like scope c = new Context(cairo); and scope Context cr as parameter to use stack allocated Context class?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that it is possible to write more comfortable wrapper for setDrawFunc(), but there is a small question.
Is it better to create a something like public draw(Scoped!Canvas) method for the DrawingArea class and allow to override it or use addOnDraw(delegate (Scoped!Context))?
And I agree that using Scoped~Context is better. Will be replaced

addOnDraw(&drawCallback);
setDrawFunc ((area, cairo, w, h, data) {
(cast(CairoText)data).drawCallback (new Context (cairo));
}, cast(void *)this, null);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

addOnDraw(&drawText);
setDrawFunc ((area, cairo, w, h, data) {
(cast(PangoText)data).drawText (new Context (cairo));
}, cast(void *)this, null);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

@@ -1,3 +1,3 @@
[submodule "wrap"]
path = wrap
url = https://github.com/gtkd-developers/gir-to-d.git
url = https://github.com/KonstantIMP/gir-to-d

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make PR to gir-to-d?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -67,18 +67,18 @@ class MainWindow : ApplicationWindow {

//HeaderBar
HeaderBar hb = new HeaderBar();
hb.setShowCloseButton(true);
hb.setTitle("Actions Demo, Click the menu button >>>");
//hb.setShowCloseButton(true);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove, don't comment

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed

*/
public this(bool defaults = false)
{
ShumateMapSourceRegistry* __p;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto for double underscore

*/
public this(bool simple = false)
{
auto __p = (simple ? shumate_map_new_simple() : shumate_map_new());

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto for double underscore

public SoupSocketIOStatus readUntil(ubyte[] buffer, void* boundary, size_t boundaryLen, out size_t nread, bool* gotBoundary, Cancellable cancellable) {
GError* err = null;

auto __p = soup_socket_read_until(soupSocket, buffer.ptr, cast(size_t)buffer.length, boundary, boundaryLen, &nread, cast(int *)gotBoundary, (cancellable is null) ? null : cancellable.getCancellableStruct(), &err);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto for double underscore

Comment on lines +70 to +72
}

return __p;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing indent?

# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA
#
wrap: soup
file: Soup-2.4.gir

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we use soup 3 or later with gtk 4? (e.g. replaced SoupBuffer with Gio Bytes)

For shumate that requires -Dlibsoup3=true though

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to use soup 3 for the latest shumate version.

Copy link
Member

@MikeWey MikeWey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all I want to say that compiletime link of gtk and other G-type libraries is useless.

What the Makefile / gir-to-d calls compiletime isn't static linking, but it will link with the dynamic libraries using the linker instead of calling ld for every function on program start up. This has a small performance benefit, and it allows ldd to actually see what libraries your application uses. That can be beneficial for creating Debian packages for example which uses ldd to figure out what dependencies are needed when creating the package.

@@ -1,3 +1,3 @@
[submodule "wrap"]
path = wrap
url = https://github.com/gtkd-developers/gir-to-d.git
url = https://github.com/KonstantIMP/gir-to-d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely

@@ -1,314 +0,0 @@
SHELL=/bin/sh
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe i'm weird, but i'm one of those people that doesn't usually use dub.

I also think distro packagers mostly prefer using the make file to build GtkD.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Sounds logically. So Makefile should be. I will try to rewrite it for the changes or return existing with some fixes.

"dependencies": {"gtk-d:gtkd":"*"}
}
]
"subPackages": [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With how this is now structured, wouldn't it be better to separate things out into different repositories?

Like whats already been done for GLib: https://github.com/gtkd-developers/GlibD

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for the core packages instead of different repositories I would recommend using subpackages in separate folders (useful to install all the common stuff at once)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With how this is now structured, wouldn't it be better to separate things out into different repositories?

Like whats already been done for GLib: https://github.com/gtkd-developers/GlibD

It will be harder to update packages I think.

}

protected:
//Override default signal handler:
bool drawCallback(Scoped!Context cr, Widget widget)
bool drawCallback(Context cr)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without Scoped you will either need to free things manually every drawCallback, or you will have a large memory leak, this because the D GC doesn't see the large Context associated with the D object and so it will take a long time for the contexts to be collected.

@@ -44,8 +44,8 @@ int main(string[] args)
mainWnd.setTitle("Simplest GLArea + CoreGL Example");

auto wnd = new CoreGL;
mainWnd.add(wnd);
mainWnd.showAll();
mainWnd.setChild(wnd);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KonstantIMP , Trying to compile this with:

$ gdc CoreGL.d pkg-config gtkd-3 gl --cflags --libs

I'm getting:

CoreGL.d:47:12: error: no property ‘setChild’ for type ‘gtk.ApplicationWindow.ApplicationWindow’, did you mean ‘gtk.Bin.Bin.getChild’?
   47 |     mainWnd.setChild(wnd);
      |            ^

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah nevermind, this is of course beacuse gtkd in my system is against gtk3 still

@MikeWey MikeWey mentioned this pull request Sep 1, 2022
@dejlek
Copy link

dejlek commented Feb 2, 2023

@KonstantIMP this is just too large PR to review...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants