GTK+ 3 support about lablgtk HOT 52 CLOSED

Wonderful. I could run a gtk3-based version of coqide and make some first Coq proof in it. I'll now clean up what I made and make a summary of what remains to be done. Thanks a lot.

from lablgtk.

I have created a new branch
https://github.com/garrigue/lablgtk/tree/lablgtk3

I contains the following:

• all your changes from lablgtk2on3-hh
• all recent changes from master
• rename lablgtk2 to lablgtk3 everywhere
• add memory management for cairo_t
• update support for GtkSpell

So no you can install it in parallel with lablgtk2.

Now, everybody needs to test.
Feel free to commit your fixes.

from lablgtk.

There are actually 2 (see gtk3 branch too).
But previous efforts tried to build from the .gir files, which requires lots of work to provide ocaml side compatibility.
We are now considering doing a light-weight port by just having (part of) lablgtk2 build on gtk3.
More fancy things can be done later if there is some work force.

from lablgtk.

Created branch https://github.com/garrigue/lablgtk/tree/lablgtk2on3 to start working on the port.
Starting working on GDK.

from lablgtk.

I can help with some guidance though. I tried to rebase the gtk3 branch on top of the master as a start but apparently there are too many changes.

from lablgtk.

The lablgtk2on3 branch now compiles and links.
Its idea is to support gtk3 using the current lablgtk2 codebase.
The current status is that I disabled everything that is not available in gtk3.
This means that lots of funtionality is lost.
In particular, all Gdk based drawing functions disappeared, and most style-related stuff.
Also many old widgets (already deprecated in gtk2) are gone, so that most of the examples do not even compile.

From now on what is needed is

• debugging (in particular update examples to use newer widgets when they are available)
  anybody's help is welcome
• connect to cairo bindings to be able to draw again. There are 2 of them, cairo-ocaml and ocaml-cairo, but they both connect to lablgtk2 in the reverse direction.
  @Chrisoo, @oandrieu do you have some idea how to do that?
• update gtksourceview bindings to gtksourceview3
• see what is needed else to have a working coqide on this basis

from lablgtk.

That's really cool @garrigue thanks for the detailed heads up, I'll try to build CoqIDE with the branch to see how far we get.

from lablgtk.

Hi @garrigue. I'm sorry for a basic question. I tried to compile the lablgtk2on3 branch but it fails with errors which I don't know how to deal with. A typical error is:

In file included from ml_gtksourceview2.c:46:
./sourceView2_tags.c:4:25: error: use of undeclared identifier
      'GTK_SOURCE_SEARCH_VISIBLE_ONLY'; did you mean 'GTK_TEXT_SEARCH_VISIBLE_ONLY'?
  { MLTAG_VISIBLE_ONLY, GTK_SOURCE_SEARCH_VISIBLE_ONLY },
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                        GTK_TEXT_SEARCH_VISIBLE_ONLY

Should I have disable gtksourceview2 at configure time? Or is it that my brew-installed gtk+3 3.22.30, gtksourceview3 3.24.9, are not the correct ones?

from lablgtk.

This is the first one: the configuration script experimentally supports gtksourceview3 when gtksourceview2 is enabled, but the actual files are not updated yet, so you should disable it, or contribute correct files :-)
(I hoped that gtksourceview2 and gtksourceview3 would be source code compatible, but this is clearly not the case.)

from lablgtk.

or contribute correct files

I just experimented removing what does not compile any more (*), then trying to compile CoqIDE. None of the removed gtksourceview2 methods are used in CoqIDE, but the compilation first fails with CoqIDE using GData.tooltips. No idea how easy it would be to find a gtk3 replacement...

(*) Basically this means:

• set_cursor_color_by_name
• process_resize/set_sizing
• all mark_category
• iter_backward_search/iter_forward_search
• GWindow.plug

from lablgtk.

@garrigue: I continued the experiment of building a version of lablgtk based on gtk+3 with which I could compile CoqIDE. After deactivating some features of CoqIDE on one side and reactivating part of the branch lablgtk2on3 which is still available in 3.22 on the other side (e.g. parts of GAction and GDraw), I could produce a bytecode version of coqide.

Unfortunately, it segfaults on the first call to GMisc.statusbar, more precisely on the first call to g_object_newv and I have no idea of what the problem is.

I don't know if this is related, when I compile in native code, linking fails with

duplicate symbol _Val_GObject_sink in:
    /Users/herbelin/.opam/4.06.1/lib/lablgtk2/liblablgtk2.a(ml_gobject.o)
    /Users/herbelin/.opam/4.06.1/lib/lablgtk2/liblablgtksourceview3.a(ml_gtksourceview3.o)
ld: 1 duplicate symbol for architecture x86_64

(On my branch, I renamed gtksourceview2 into gtksourceview3 - not sure it makes sense after all, rather than dropping the 2.)

Here is otherwise an approximative list of what needs to be changed at the level of CoqIDE:

• GtkTooltips -> GtkTooltip
• GtkList -> GtkTreeModel
• Part of GtkComboBox -> GtkComboBoxText
• GtkFileSelection -> GtkFileChooserDialog
• Bitmap -> Cairo (?)
• Tooltips -> Tooltip (done)
• Adapting Color (done)
• to understand the changes around GUtil.add_ml_signals causing a mysterious error The instance variable obj cannot be accessed from the definition of another instance variable
• later on, for gtk+4: GtkTable -> GtkGrid and GtkStyle -> GtkStyleContext + a few punctual changes

So, all in all, I suspect that the changes would require maybe roughly a week for CoqIDE and little work on the lablgtk side (since the alternaive features to use are mostly already available in lablgtk2), once it is clear that we can make lablgtk3 working (w/o segfault).

from lablgtk.

I you can point me to the repositories with your code, I can try debugging.

from lablgtk.

I pushed a branch lablgtk2on3-macosx-compile which extends the branch lablgtk2on3 with a removal of what uses GTK_SOCKET so it compiles for me (probably needed because on MacOS X as support for GTK_SOCKET seems platform dependent).

The branch compiles for me with configure --without-gtksourceview2 (both byte and opt).

I have a file in the branch example_statusbar_segfault.ml which when compiled with ocamlc -custom src/lablgtk.cma -I src/ example_statusbar_segfault.ml produces an executable which segfaults on calling g_object_newv.

(I have otherwise another branch lablgtk2on3-hh which allows to compile a modified version of coqide - the history is not very clean though.)

from lablgtk.

@garrigue: I solved the segfault problem by calling GtkMain.Main.init earlier in coqide (thanks to @thierry-martinez). I now reached a situation where I get Fatal error: exception Failure("Gobject.unsafe_create : type GtkTable is not yet defined"). Note that I reactivated GtkTable since it was marked deprecated only since 3.4 and then not supposed to be removed yet. To be sure, I added a few bindings for GtkGrid which is the recommended replacement since 3.4, but I get instead Fatal error: exception Failure("Gobject.unsafe_create : type GtkGrid is not yet defined"). Does the message come from something I forgot to do in the lablgtk archive or simply from gtk's G_TYPE_FUNDAMENTAL. But in the latter case, I don't see why these both classes would be invalid (both are supposed to exist in 4.0 > gtk >= 3.4).

Added: an example showing the failure (with Table) using my branch lablgtk2on3-hh is:

let _ = GtkMain.Main.init ()
let w = GWindow.window ~title:"demo" ()
let _ = GPack.table ~rows:1 ~columns:1 ~packing:w#add ()

from lablgtk.

You should add a call to gtk_grid_get_type in ml_gtkpack_init at the beginning of ml_gtkpack.c. Only widgets registered via one of those init functions can be created by Gobject.unsafe_create.

from lablgtk.

Great news. Then it is worth having a package for lablgtk2on3, even if it is only intended for projects which require 3-only dependencies.

from lablgtk.

Then it is worth having a package for lablgtk2on3

I think so.

How do think this could be done:

• Do you plan to have the same code able to compile against gtk2 and gtk3 (using ifdef also at the ocaml level), or different source archives?
• Since lablgtk2 has a 2 in its name, I guess the plan would be to call it lablgtk3? And similarly for gtksourceview3.cma? Note however that the current CoqIde explicitly refers to the modules named GSourceView2 and GtkSourceView2. Shouldn't these latter modules be named without a number and automatically be attached to the gtksourceview version they depend on?
• Several classes deprecated during the gtk+3 phase could be kept (e.g. GtkImageMenuItem in 3.10, GtkTable in 3.4, all available in the last 3.22 version)? Would you see a problem at restoring them? I already did it for Table, Style, Action and I could do it for more of them.

PS: I talked with Virgile Prevosto (for Frama-C) and Claude Marché (for Why-3) who both would be relieved too to be able to use lablgtk with gtk3.

from lablgtk.

The reason we have a version number in lablgtksourceview is that lablgtk2 supported both gtksourceview1 and gtksourceview2. I'm not sure it was a good idea, but then I wasn't involved in supporting that widget.

Since I suppose it is going to be a pain for coqide (and why3 and frama-c) to support different APIs for lablgtk2 and lablgtk3, the question is whether this is reasonable to make lablgtk3 a requirement for these applications, or should we try to make lablgtk2on3 a strict subset of lablgtk2 (so that these applications can be compiled against both of them).

If we chose to force a dependency on gtk3, then different module names are not a big problem.
But I'm happy to follow you on removing the number in lablgtksourceview, since gtk3 only supports gtksourceview3 anyway.
However, the second approach (source compatibility) requires much more care. I'm not even sure this is possible,

Considering re-enabling deprecated widgets, I'm perfectly happy with that.
I had to remove lots of stuff to create fast enough a version that would compile, but for compatibility we want to keep as many widgets as possible.

from lablgtk.

Since I suppose it is going to be a pain for coqide (and why3 and frama-c) to support different APIs for lablgtk2 and lablgtk3, the question is whether this is reasonable to make lablgtk3 a requirement for these applications, or should we try to make lablgtk2on3 a strict subset of lablgtk2 (so that these applications can be compiled against both of them).

From the point of view of CoqIDE, as far as I can tell up to now, it seems enough to use features already present in gtk+2 to be compilable against gtk+3 (even if some of these features have been deprecated in late versions of gtk+3). For instance, Tooltips is not in gtk+3 but Tooltip is both in late gtk+2 and in gtk+3, idem for ListStore, etc. The only non-compatible thing would precisely be the module name GtkSourceView2 vs GtkSourceView3 (but this can be easily configurable).

However, even if it should be possible to build the same code of CoqIDE both on gtk+2 and gtk+3, I'm unsure it is really worth. I guess that gtk+3 is more liable to be available everywhere than gtk+2, so I don't see a problem as demanding gtk+3 mandatorily. So, the question of having the same compatible source code or not to build lablgtk2 and lablgtk3 could (I think) be considered purely from the practical point of view of lablgtk itself. Somehow, the question seems to me to be whether it is more practical to have one branch so that extensions/fixes which are valid for both lablgtk2 and lablgtk3 can be done only once, or if it is more convenient to have distinct archives/branches and to push the extensions/fixes which are valid for the two branches twice. (Maybe it is the latter which shall be simpler?)

Considering re-enabling deprecated widgets, I'm perfectly happy with that.

Ok. For the record, I'm currently working on my extension lablgtk2on3-hh of your branch which I push regularly (history is not very clean and changes not systematically made very rigourously or consistently though).

from lablgtk.

A few remarks:

• at least for ocaml-cairo the dependency on lablgtk is for examples, and is not crucial
• I don't know though how strongly lablgtk should depend on cairo. Could it be that it depends on it only for types (such as cairo_t)?
• I have a problem which I don't know how to solve. With master, the following works:

class message_view_signals_impl obj (pushed : 'a GUtil.signal) =
object
  val after = false
  inherit GObj.misc_signals obj
  inherit GUtil.add_ml_signals obj [pushed#disconnect]
end

but, with lablgtk2on3, it says:

Line 4, characters 10-31:
Warning 13: the following instance variables are overridden by the class GObj.misc_signals :
  after
The behaviour changed in ocaml 3.10 (previous behaviour was hiding.)
Line 5, characters 31-34:
Error: The instance variable obj
cannot be accessed from the definition of another instance variable

Would you have an idea of what happens?

from lablgtk.

For ocaml-cairo, this depends on whether we want to provide extra functionality inside lablgtk as before. Otherwise we could indeed just return a Cairo context and let caml-cairo do all the work.
We still need to be sure that we use the same internal representation.

For the typing error, due to the disappearance of the GtkObject widget I tweaked a bit the class hierarchy in GObj, and it looks like it was a bad idea. I'm looking into it.

from lablgtk.

For the question of compatibility, since you introduced the Grid widget which exists only in Gtk3, I think the point is moot: lablgtk3 will be independent of lablgtk2, trying to keep maximal compatibility but not being too strict with that.
lablgtk2 has been in comatic maintenance mode for a while, it can stay that way.
The question is more the amount of effort we put into adding new widgets to lablgtk3.

Also, it would be a good idea to just remove the old versions of gtksourceview from the configure script, since they won't work anyway.

from lablgtk.

I have opened a PR on your branch for your type error:
herbelin#2

When you're happy with your changes, I'll merge that on the original lablgtk2on3.
Or you can do it yourself now.

Then when it's stable, we'll try to make a release.
I was also thinking of reusing the lablgtk3, but apparently Benjamin Monate had already done some work there too...

from lablgtk.

For the question of compatibility, since you introduced the Grid widget which exists only in Gtk3, I think the point is moot: lablgtk3 will be independent of lablgtk2, trying to keep maximal compatibility but not being too strict with that.

Note that I don't need Grid for CoqIDE (since Table is only deprecated from 3.4). I added Grid more to have an idea of how easy or not it was to add a new feature. But, yes, eventually, we certainly want to add features which are only in gtk3 (or even gtk4).

The question is more the amount of effort we put into adding new widgets to lablgtk3.

I don't know what to say here. GTK does not seem "fashionable" these days: around me, people (e.g. Benjamin M) are advocating "web technology" for new GUIs. Some Coq people also plan to develop a new GUI based on LSP/VSCode. So, it is difficult to evaluate if there is a need for more than maintaining the existing. So, this may mean only supporting new features on a by-need basis.

On the other side, I did not follow the introspection thing, but adding Grid was somehow canonical, thanks to propcc which I found wonderful. Some extra boilerplate in gPack.ml, gPack.mlicould also have been automatized (e.g. by adding the OCaml extra creative work directly in the .props file). So, maybe, it would be possible to get the best of two approaches: automatic support for all bindings + ability to write "smart" OCaml function on top of them.

I guess that it depends also on how many people are interested to be involved.

Also, it would be a good idea to just remove the old versions of gtksourceview from the configure script, since they won't work anyway.

Yes.

from lablgtk.

When you're happy with your changes, I'll merge that on the original lablgtk2on3.
Or you can do it yourself now.

If you agree, I'd be tempted to eventually first clean the history by squashing my commits restoring features that you removed with the commits you made to make it compile first.

Then when it's stable, we'll try to make a release.

I'm incompetent on this, so, when ready, I'd prefer you do it.

I was also thinking of reusing the lablgtk3, but apparently Benjamin Monate had already done some work there too...

Is that the branch with introspection? What would mean reusing it?

from lablgtk.

I was just thinking of using that name, but there was already a branch. So we have already branches called lablgtk3, gtk3, gtk3.x in the repository, doing more or less the same unfinished thing :-)

So maybe I'll just go on using the lablgtk2on3 branch, and release it as labkgtk3...

from lablgtk.

I want to do some squashing, it means that you will have to overwrite the lablgtk2on3 branch in the repository?
I'm fine with it; I'll do nothing on that branch until you push.

from lablgtk.

So maybe I'll just go on using the lablgtk2on3 branch, and release it as labkgtk3...

OK.

Among the other points I met with porting CoqIDE, I have:

• GWindow.window now takes wmclass rather than a pair wm_class and wm_name. I'm perfectly ok with the change but since this is now the only change which introduces an incompatibility between lablgtk2 and lablgtk3, I'm mentioning it.

I want to do some squashing, it means that you will have to overwrite the lablgtk2on3 branch in the repository?
I'm fine with it; I'll do nothing on that branch until you push.

So, I first squash/combine my commits with yours, then push-force on lablgtk2on3, then you do whatever you want with the branch, right? Let's say that I push-force tomorrow around 11-12am Paris time (7-8pm Nagoya apparently). OK?

from lablgtk.

@garrigue: I made something a bit crazy which is to rewrite the history on a component basis. I say "a bit crazy" in the sense that it leads to about 160 commits, which however roughly decompose themselves into the following categories:

• Commits which could be added to gtk2 (extra methods/widgets already in gtk2, bug fixes)
• Maintenance commits (configure, Makefile, propcc, ...)
• Removal/modification of gtk2 features removed/changed in gtk3
• Re-emulation of some specific lablgtk2 functions on top of gtk3
• Two remaining (unstructured) big commits about .c files

The experience is in my branch lablgtk2on3-hh-structured. Otherwise, the branch lablgtk2on3-hh has the same content on top of yours. There is still some work to do on this structured branch, and ideally one would like to also minimize the range of commits between which it does not compile.

In any case, the ball is basically in your hand to decide what to release.

I fixed a few problems of CoqIDE which now apparently behaves as if built with lablgtk2 (up to a clist to be changed)

I saw that there is a GtkSourceView4 building on top of Gtk3, so, maybe the name GtkSourceView3 should be used, with a 3 referring to GtkSourceview, not to Gtk..

About the structure of the archive, I have a commit "Adding file structure for compiling gtksourceview3" which I don't know if it is like you'd like it to be (it copies what is done for gtksourceview2 for gtksourceview3).

At some time, will you prefer to have the code being deactivated by means of comments (/* */ or (* *)) to remain like this or simply to be removed?

I have the remaining following configuration problem: the gtk_plug_new does not exist in my MacOS X brew gtk3 package; I don't know if this is a question of configuration of brew or if it is not available on MacOS X. In any case, it should be detected at configure time but I don't know well how to ensure that.

I restored a few gtk2 methods which are still available in gtk3. Tell me if it is not ok. I kept wmclass, which matches the corresponding property.

I finally prefer to not take the responsibility of overwriting the branch. I'd prefer you do as you think it should be done.

from lablgtk.

Thanks, but it's a bit too many commits for me. The naming is helpful, but I would still be confused.
I'll probably just merge lablgtk2on3-hh. I don't think the glitch in the history will cause any practical problem. But it will probably have to wait until Thursday, so you're free to go on working on your branch.
I have renamed the lablgtk3 branch into lablgtk3_monate, so I will eventually lablgtk3 as name for the main branch, and rename the libraries and scripts as lablgtk3, to allow installation in parallel with lablgtk2.

For the dead code, I have no strong preference, but experience shows that sometimes one needs to resurrect it, so leaving it around can be useful. This said, we know where to find it anyway.

I'm not sure for the problem with GtkPlug. I seem to remember that it worked on gtk2 even with the quartz backend, and I think it compiled for me with the gtk3 from macports. This said, I've not seen it used with lablgtk ever, so this doesn't matter much.

from lablgtk.

I'll probably just merge lablgtk2on3-hh

Ok then.

so I will eventually lablgtk3 as name for the main branch, and rename the libraries and scripts as lablgtk3, to allow installation in parallel with lablgtk2.

OK.

For the dead code, I have no strong preference, but experience shows that sometimes one needs to resurrect it, so leaving it around can be useful. This said, we know where to find it anyway.

OK, so doing nothing.

I'm not sure for the problem with GtkPlug. I seem to remember that it worked on gtk2 even with the quartz backend

For gtk2, brew installed a libgtk-quartz-2.0.0.dylib which had plug as symbol, but for gtk3, it installed a libgtk-3.0.dylib which has not. Anyway.

Thanks!

from lablgtk.

@herbelin there is a Dune version for this in https://github.com/ejgallego/lablgtk/tree/lablgtk2on3-hh%2Bdune

You may find it quite useful to develop CoqIDE.

from lablgtk.

Hi,
I am trying to port Matita to lablgtk3, but I have immediately a problem with glade support. The configure looks for a libglade-3.0. Is it supposed to exist? glade seems to be entirely deprecated and I was not able to find C code installing a libglade-3.0.so.

C.S.C.

from lablgtk.

Unfortunately, there is no libglade for gtk3. There is a new object called GtkBuilder which is supposed to allow to do the same think, but it is not supported at this point. Contributions are welcome!

from lablgtk.

Now, everybody needs to test.

I could compile CoqIDE with the lablgtk3 branch without apparent problems. Thanks a lot for all the work.

I still did not investigate how to use Cairo for reimplementing the pixmap-based progression bar of CoqIDE though. As far as I understand, this shall require an extra dependency in ocaml-cairo, right?

from lablgtk.

Hi Jacques,
I plan to contribute the binding for GtkBuilder soon.

In any case the configure of lablgtk3 has been upgraded in a wrong way, because it looks for the non existent lablgtk3.

from lablgtk.

Update: my student Andrea Condoluci is about to issue the first two pull requests. What we did:

1. we added the binding for a missing property (unreleted to glade/gbuilder)
2. we added a minimalist binding for GBuilder (just 1 property, one smart constructor and one method). The binding is sufficient to automatically load an XML file and retrieve the widgets.

A final pull request is required to have a working system: we need to port lablgladecc to the new GBuilder/XML file format. Without it is too tedious to use an XML-ized interface. It seems we are very close to that and we expect to commit very soon.

It seems that some love is required for GFileChooserDialog because I did not manage to extract the selected file from it. GFileChooserDialog is the replacement for GFileSelection that is no more. I will take care of it as well if nobody does before me.

Right now I have a sort-of-working Matita, without the menus :-) UIManager is no more as well and I am still wondering how to use the new glade tool to add MenuItems to a menu.....

from lablgtk.

Update: today I will issue a pull request that

1. removes all code related to libglade, that exists no more in gtk3
2. restores functionality of lablgladecc

Notes:

• lablgladecc is no longer based on libglade; it now uses GBuilder
• the XML format is new and different. There is a standard tool to migrate from old .glade files
  to the new .ui files. I used it for Matita and the result is a starting point, but not directly usable.
  I was able to obtain a working .ui file with some hours of work
• the pull request yields a usable lablgladecc, but the behavior is different from the old one.
  In particular the old one used to build the widgets on demand while the new one builds all of them
  up-front.

After this pull request I will work on trying to restore the behavior of the old lablgladecc.

from lablgtk.

The work on lablgladecc is now completed and only needs to be pulled. Practically all useful functionalities of the old lablgladecc are restored. Jacques, it would be great if you could accept the pull request and release on opam a third beta version.

B.t.w., where is the opam file stored? It would be easier if opam file was committed in the lablgtk3 source tree, so that one could install the package locally.

from lablgtk.

The opam file is in the opam repository.
I'm not sure which part of it could be in the package itself.
Or should we just merge @ejgallego patch for dune support now, at least for the lablgtk3 branch, since it seems to do be able to do that via empty opam files?
(Sorry, I'm not used to opam at all, and I'm just updating the old files...)

from lablgtk.

Concerning lablgladecc3, I've merged your PR, but could you also update the files in examples/glade, and also the README ?
This would be helpful for people who want to use it.

from lablgtk.

Sure, I will update the example/glade and README and trigger a new pull request.

About opam: I am (very) old school and not an opam expert myself, but I know of several projects that include an opam file in the upstream repository. To install the package without publishing just do "opam install .". To trigger the pull request for opam, just use the opam plugin "opam publish" and it will do all the dirty work. The lablgtk3 case could be more complex, though. Opam experts can provide advice.

from lablgtk.

I made the pull request for README and examples/glade/*

from lablgtk.

Hello, and thanks for all the work.

I managed to obtain a Frama-C GUI that is mostly working with lablgtk3 beta3. There are two points that are problematic so far:

1. As far as I can tell there is no binding for gnomecanvas (if I understood correctly, this library is itself tied to gtk2 and obsolete, so that this is not really surprising). Frama-C does not use it directly, but DGraph, a module of ocamlgraph for visualizing graphs does. I'll check with the ocamlgraph authors whether there are workarounds.

2. I've encountered a Failure("Gobject.create") while creating a statusbar with ~has_resize_grip:false. A minimal example to reproduce that is:

open GMain

let locale = GtkMain.Main.init ()

let main () =
  let window = GWindow.window ~width:320 ~height:240
                              ~title:"Simple lablgtk program" () in
  let _statusbar =
    GMisc.statusbar 
      ~has_resize_grip:false
      ~packing:window#add ()
  in
  window#show ();
  Main.main ()

let () = main ()

if you comment the ~has_resize_grip:false line (or compile against lablgtk2 of course), everything works fine.

from lablgtk.

About Virgile's point 1: is Cairo the intended replacemente for GnomeCanvas?
I am also interested in porting Cairo support to lablgk3 and I have an almost working implementation (see issue 6. Maybe it could be possible to port ocamlgraph to cairo (I have no idea how btw)

from lablgtk.

This is what says the Gtk-3 transition page. GnomeCanvas was deprecated because Cairo is sufficiently expressive, and already replaces the original Gdk drawing functions.

from lablgtk.

For the statusbar problem, indeed the property is not in Gtk-3. I removed it, and added a new style property.

from lablgtk.

@vprevosto I have made a pull request to enable proper support for cairo&friends (not merged yet).
There you can see example/nd.ml where I draw some items made of complex combination of text and graphical elements and where I react to mouse events by detecting what item I am clicking/moving on. I don't know what DGraph does, but I think that what I did in my example is the exact functionality required by DGraph.

from lablgtk.

Thanks. I don't know much of DGraph myself (apart that it needs gnomecanvas), but some of my colleagues do, we'll try to have a look at it.

from lablgtk.

OK, in fact I forgot another issue: Frama-C did use the set_mark_category* methods of source_view, that haven't been ported to gtk3, probably because this has been superseded by a new structure GtkSourceMarkAttributes. I've started a branch for that. It only contains the bare minimum to do what I want (basically, displaying icons in the left gutter of the source_view object, but given my knowledge of lablgtk3, if someone could have a glance at it for obvious mistakes before making an official PR, I'd be thankful (examples/sourceview/test2.ml appears to be working).

from lablgtk.

@vprevosto It seems perfect to me, but for the declaration of the C function val_gtksourcemarkattributes that seems useless to me (no lists of that class are ever used) and can be removed. Can you also add lines to the README file for the additions you made?

from lablgtk.

@garrigue so I guess this can be closed now too?

from lablgtk.