Can this repo be removed / deprecated?

[blueyed]

No description provided.

[psychon]

Same story as awesomeWM/oopango#1. Let us keep the discussion here.

[blueyed]

s/here/there/ ?

Closing this issue then. Better to have it as a reminder.

[Nixola]

Can I ask why should this be deprecated? Is there another, more up-to-date, repo anywhere, or is the library itself deprecated?

[psychon]

I only looked into this for awesome and awesome uses LGI instead of this (much more powerful and easier to maintain). @Nixola What are you using this for?

[Nixola]

I'm using it in order to render things (lines, mostly) on a server (thus with no GPU or X server or screen or anything). Now if only I could get it running on said server (No package 'cairo' found even though libcairo2 is installed, on Ubuntu 14.04) I could confirm it can be used for that, but it does work on my system in a tty.

[psychon]

Assuming you are talking about LGI: Look for a package like cairo-gobject... uhm libcairo-gobject2

[psychon]

Wait, no, you are not talking about LGI, but about oocairo? libcairo2-dev: https://packages.debian.org/stretch/libcairo2-dev
(Still, I would prefer LGI over oocairo)

[Nixola]

Welp. I installed it and could configure (I was talking about oocario), but make says "Nothing to be done for 'all'.", so I kind of can't build it? Also, I kind of haven't ever heard of LGI; does it use Cairo as well, or does it allow me to render things to an image with no graphics context or device?
EDIT: well, I tried LGI as well, I get Typelib file for namespace 'cairo' (any version) not found when trying to access lgi.cairo. I feel like this is getting out of scope though.

[psychon]

Dunno about the "nothing to be done". That LGI-one should be fixed by installing libcairo-gobject2, but yeah, you are right about scope. :-)

[osch]

I'm insterested in using oocairo and, if necessary, improving it. E.g. providing a rockspec and submitting it to luarocks. Also a new version number for current master would be useful. Are you accepting pull requests? Or should this repo be considered as dead/frozen?

[psychon]

@osch Any specific reason why you prefer oocairo over lgi?

It depends on how much work you want to do on oocairo. The simplest option might be to just fork this.

[osch]

Any specific reason why you prefer oocairo over lgi?

First of all I want to have as less dependencies as possible to other libraries and especially are trying to avoid gnome related stuff (gnome projects lost backward compatibility in the past too often, latest example pango 1.44).
Furthermore oocairo is much easier to understand than lgi. I can understand the source code of oocairo immediately by just using the cairo and lua documentation whereas all gobject related things are much more complicated. For example it is very easy for another lua c module from outside oocairo to transfer a cairo_t* into an occairo lua userdata whereas I didn't find an obvious solution for this using lgi.

The simplest option might be to just fork this.

Yes, I also thought about this but before doing so, I wanted to clarify the status of this repo to avoid unnecessary forks. If I'm going to fork I'm also undecided if the fork should have a different name or just keep the name oocairo (both variants could cause confusion somehow).

[psychon]

For example it is very easy for another lua c module from outside oocairo to transfer a cairo_t* into an occairo lua userdata whereas I didn't find an obvious solution for this using lgi.

On the C side, just use create an extra reference and use lua_pushlightuserdata(), for example:
https://github.com/awesomeWM/awesome/blob/3cc43f1be3fb29fa3220a31de8cecb846661134c/objects/client.c#L3418-L3419

On the Lua side, use the "constructor" of the respective type, e.g. require("lgi").cairo.Surface:
https://github.com/awesomeWM/awesome/blob/3cc43f1be3fb29fa3220a31de8cecb846661134c/lib/gears/surface.lua#L64

With LGI, this is totally not type safe while (AFAIR) oocairo requires the C code to do stuff in a type safe way...

I propose that you just send PRs here and if you decide that I am too slow in merging (or complain too much), you can still fork. Note that this is already a fork of another project which was already called oocairo, but I do not remember the details of where that code came from. And I have not looked at this oocairo in ages.

[osch]

With LGI, this is totally not type safe while (AFAIR) oocairo requires the C code to do stuff in a type safe way...

Yes oocairo is safer here because full lua userdata is used instead of lightuserdata, so this is IMHO an additonal reason for using oocairo.

I propose that you just send PRs here

OK, but in the first place it would be good if you could tag current master as v1.5 to have an official release of the current version. I could then prepare and submit a PGKBUILD to AUR. Regarding luarocks: I could supply rockspecs as PR. Do you want to upload the rockspecs to luarock, of should I do this? The luarocks entry is tied to the account that uploaded the rockspecs, but it's no problem to contact luarocks maintainer and transfer ownership if this should be necessary.

[psychon]

Do you want to upload the rockspecs to luarock, of should I do this?

Feel free to do this. I never uploaded anything to luarocks before.

if you could tag current master as v1.5

Which version do you mean exactly with current master? git tag -a -m 'Version 1.5' 2aba6f923a04376397f85eda0e76e612c236860d or git tag -a -m 'Version 1.5' c0b15cd4aa6e3024b7ec593c27585fc04e76a000? (= after or before your latest PR?)
Also, should I increment the version number in configure.ac first?

Looking at the git history, I guess I should do something similar to 3eef5d8 (wow, it's been almost nine years since 1.4).

[osch]

Which version do you mean exactly with current master?

wow now it's going faster than I imagined: yes it would be cool to include my latest PR, so I would tag after 2aba6f923a04376397f85eda0e76e612c236860d, but as you wrote:

Also, should I increment the version number in configure.ac first?

ah yes, you are right, this must be done before tagging. I would than prepare & test a rockspec for version 1.5 and also a PR for the versioned rockspec, although the PR is not necessary but just for completeness. Regarding the 1.5 rockspec this is a hen-and-egg problem: the 1.5 rockspec can only be tested after 1.5 is tagged. But I don't see any problems if the 1.5 rockspec is not included in the tag. Perhaps it's also silly to commit the versioned rockspec at all, I'm not sure about this.

[psychon]

@osch Done