Have you been able to build this to a working binary?

[SecareLupus]

I'm working on forking celtx, removing all original branding, ads, and ties to their services, and adding some new features down the road, but the sticking point right now is I can't get it to build. Have you been able to build it at all? I know this is a particularly old project, but now that it isn't maintained by them, it would be great if we could get a replacement forked and available.

[mapofemergence]

@SecareLupus @n8willis I know this was opened a while ago but did you manage to build it, in the end? I cannot do much myself at present, for lack of experience and time, but I'd be keen to follow anything happening on this front (if anything's happening)

[SecareLupus]

I did not, there were many dependencies that have upgraded past compatibility, and while I was able to fix some of the issues, porting to the new versions of libraries, there were more that I couldn't quite figure out. I'd like to attack it again at some point soon, but right now I've backburnered my work on this.

Edit: So, I've been hacking on this, and gotten further, but still not able to get it to build. My fork of this repo is up to date with my progress. The current error is with a line that I'm almost certain is right, as it's a mozilla file, and not an out of date one, as far as I can tell.

[mapofemergence]

hey @SecareLupus thank you so much for the update. I tried to go through the commits, to figure out if I might be helpful someway, but I'm afraid it's still way over my head :/

I also began reading the build instructions at mozilla http://www.mozilla.org/build and I suspect it'll be a long way for me. Nonetheless, I'd appreciate if you can keep pushing your commits; I'm now watching your repo and, worst case, it'd be an opportunity for me to learn. In the fortunate case I manage to get anywhere meaningful, I'll definitely let you know (although I'm on Windows; I assume you're building on Linux, right?)

Thank you for the time you're putting on this. I believe it's a cool thing

[SecareLupus]

The issue I've been seeing with mozilla.org/build is that it's pretty different from a few years ago, when celtx was buildable. I've jumped on the wayback machine to get instructions contemporary to the project, but have run into issues with the gcc version being too high, and not allowing some sloppier c++ patterns that were okay back when it was written. Currently I'm trying compilation on a vm running Ubuntu Hardy Heron, which was out around the time this compilation would have worked.

There's some weird issue with localization, I think some of the locales did not get packed with the rest of the code, so build was failing when it tried to load them all. For now, I ripped out all but the en-US locale, and it's building atm. we'll see if it gets any farther on gcc 4.2 than it did on 6.3. Once I know it can be built, i can start porting it to newer compilers and maybe move it out of xulrunner into a more modern toolkit.

Update: It built fine, and is usable. now just to make it modern... Looks like the main issue was that gcc outpaced the code. I'm not sure yet about cross compiling for windows, but it looks like Hardy Heron is the best dev environment to get it thrown together quickly.

[mapofemergence]

Rezpekt man! That sounds indeed quite a progress. Localization does not sound like a big deal, does it? I mean, even sticking with en-US for a while sounds total acceptable.

Again, I'm a total noob, but if that used to compile fine for windows too, I'd assume there shouldn't be too many more issues with dependencies, than you had on Linux (although not sure if I could hope in any less). I might give it a try this week and see if I manage to get anywhere, by setting up a solution in VS and (see where I fail to) build on Windows...

P.S. is there a reason why you don't have the Issues section open on your repo? Ii feels a bit odd having this conversation here... :/ I mean, it is the repo you forked from but, still, all the updates are on yours. Is this a common practice I'm not aware of? Also, I just forked your repo, should I have forked this one instead?

[SecareLupus]

I've switched the default branch on my repo to a reverted codebase, and updated it with instructions on getting it to build inside a vm. There's probably an easier way, and I do want to redo the changes i made on my master branch, but I'm going to start from working, rebrand first, and then update if possible. I've tried cross-compiling for windows, but currently the build is broken, and I haven't yet looked into why. If you can get it working in VS, I'd love to add windows compilation instructions.

As to the issues section on my fork... I thought it was open. I'll look into fixing it.

[guerrrero]

Oh guys how to buiuld Celtx on Raspberry Pi lol?

[SecareLupus]

lol. good luck. I think your best bet is to take a look at this thread, which is about compiling Nightingale for raspberry pi. Nightingale is an audio player built on the same platform as Celtx. I don't know how easy/hard it would be to do so though.

[SecareLupus]

http://forum.getnightingale.com/thread-865.html

Sorry, forgot to include the actual link that was supposed to go with that comment...

[guerrrero]

But Celtx as Nightingale is mozilla-based app: https://www.mozilla.org/en-US/about/mozilla-based/ and might builds like Firefox, no? And I heard that FF compiling needs more than 2Gb RAM, so...

Huh, I'm newbie in various-compiling-things, is it possible to build a RPi Celtx package on other machine and deploy to RPi? Don't know how to say correctly, sorry.

[SecareLupus]

Celtx is built on an abandoned mozilla platform, yes. So is Nightingale. I believe it's called XULRunner, though while doing research to get as far as I did, I found a couple similarly named related projects, and I'm not entirely sure where the dividing lines lie between them. In any case, all modern libraries are out of date. I recommend looking into cross compiling for raspberry pi, using libraries contemporary to the last update of the project. I used the VM that I did specifically because it was live around the time that Celtx was discontinued, and thus would have the proper dependencies installed.

You're not picking an easy project to learn about compiling from, tbh.

[guerrrero]

At the end of compiling your fork (thanks for the readme!) I've got this:

make[4]: Leaving directory '/home/pi/webdlls/drood/objdir/js/src' /home/pi/webdlls/drood/mozilla/config/rules.mk:636: recipe for target 'libs_tier_js' failed make[3]: *** [libs_tier_js] Error 2 make[3]: Leaving directory '/home/pi/webdlls/drood/objdir' /home/pi/webdlls/drood/mozilla/config/rules.mk:648: recipe for target 'tier_js' failed make[2]: *** [tier_js] Error 2 make[2]: Leaving directory '/home/pi/webdlls/drood/objdir' /home/pi/webdlls/drood/mozilla/config/rules.mk:605: recipe for target 'default' failed make[1]: *** [default] Error 2 make[1]: Leaving directory '/home/pi/webdlls/drood/objdir' client.mk:1113: recipe for target 'build' failed make: *** [build] Error 2

What's this? Missing dependencies?

libs_tier_js etc

[guerrrero]

Found same problem in other thread, they talked about anything named "clang++" https://github.com/MoonchildProductions/Pale-Moon/issues/16

Trying to install...

[SecareLupus]

I'm not sure precisely what's going on, but in general "recipe for target <> failed" means that there was a makefile that explained how to build a particular chunk of the application, but the "recipe", or set of instructions, didn't run successfully. In the case of the first error, the makefile that failed was /home/pi/webdlls/drood/mozilla/config/rules.mk, and line 636 presumably has (part of) the recipe for target 'libs_tier_js'

the three recipes that are failing are (in this order) libs_tier_js, tier_js, default, and build. What this tells me is that the build recipe attempted to run the default recipe as part of its set of commands, which then tried to build tier_js, which then tried to build libs_tier_js. This is a pretty standard dependency tree, but when libs_tier_js failed to build, it prevented everything up the tree from building.

So there's either a bug in libs_tier_js, or an incompatibility with compiler versions that's affecting the compilation of libs_tier_js, and I'm not sure which it would be, or what the precise cause would be in this case. In my experience, I think those sorts of errors mostly came from compiler/dependency version issues, but it was about a month and a half ago when I last worked on massaging this project into working order.

[SecareLupus]

oh, and recipes usually take the form of...

recipeName:
    gcc -o outputfilename somelinkedlib.o orwhatever.o iDontWriteMakeFiles.cpp

[guerrrero]

These russian guys talk about old and new libs as you: https://forum.mozilla-russia.org/viewtopic.php?id=46694 Maybe I must downgrade my deps, but dunno to what revisions. Will try.

[SecareLupus]

I used the wayback machine to find the page about compiling firefox in ~2007 or something. I figured out the version of firefox it's built on (but don't now remember, 2.6 maybe?), and then looked for compilation instructions for that version. Once I found the page with information contemporary to that version of firefox, I used that to identify dependency versions.

I think I tried a bunch of stuff before settling on an old version of linux in vm as my build environment. I couldn't quite get my dependencies in order otherwise.

[guerrrero]

Yup, you wrote about it above.

Maybe founding the right libs will be the right decision.

https://forum.mozilla-russia.org/viewtopic.php?pid=452632#p452632

I think I'm beginning to understand. I'm trying to compile the latest version of Firefox, which seems to be 3.6. And in the repository - the version of Iceweasel 3.0.6-3. If the old version is in the repository, then the libraries are also old. To get everything right, you need to update the libraries. Unfortunately, there is a list of required libraries on this page: libasound2-dev, libcurl4-openssl-dev, libnotify-dev, libxt-dev, mesa-common-dev, autoconf2.13, yasm, but no versions are specified. How do I know the versions of the required libraries?

Below:

Look through about:buildconfig with what flags it compiles.

But how to about:buildconfig in Celtx?

[vitacon]

So, is this a dead end? =(

[SecareLupus]

@vitacon, I have been distracted by other projects, I'm sorry to say, and I'm sure the code hasn't gotten any less stale in the last three years. I received an email awhile ago from someone (sorry if it was you) looking for ways to get it working with some standardized file formats and packaged in an .AppImage (I think, going on memory), but I lost the thread of our conversation somewhere in the shuffle.

My thoughts on this project are the following:

• It would be awesome to get it working again, there isn't, to my knowledge, a comparable alternative to the utilities the project maintained.
• I don't have any experience with XUL in general or XULRunner in particular
• I read somewhere that it might be possible to run XUL apps on Firefox 3 instead of XULRunner, which I believe was depreciated midway through Firefox 2. If this is possible, it would likely allow for the use of some slightly newer libraries, which might make the compilation process easier.
• I wonder whether it might be a better use of time to port the data structures and processes to another language, or at least another GUI toolkit. I'm particularly fond of Dart, and Flutter just went 2.0 with native compilation for all platforms, but that's an undertaking and a half, and would it even be the same project at the end? Debatably not.

I can take another look at the code tonight, I've got a bit of free time available, but yeah, I think the question is really, "Do we try to make obsolete code usable more than a decade after EOL, or do we treat it as a roadmap and algorithm design strategy for a re-imagining of the project from scratch?"

I'm preferential to the latter, but I'm not sure a project of that scope is feasible without a small team collaborating, preferably with more experience in the existing codebase than I have at present.

[SecareLupus]

FWIW, it's probably worth scrapping the current mainline version of my repo and using as a reference the initial commit again, because I suspect I broke a thing or two in my find-and-replace party.

[amworsley]

My github fork is https://github.com/amworsley/open-celtx

I got this building as a debian package and submitted it to be sponsored but that link failed as no one sponsored it and after six months the link expired.

It was done because Andrew Pam still uses the package and wanted something compiled more recently with some bugs fixed.

I never use it myself in practise so I don't think I can put any work into it other than to help out or for practise at debian packaging.

It is so big and complex (and I don't understand how to use it) that I wouldn't know where to start with re-implementing it in another language or what ever. Perhaps it is best served as a test case to compare any functionality with a new version. e.g. Can the new software import old projects and display them?

If a lot of it can be done via external libraries this would be the best way forward.

Thanks

Andrew Worsley

On Mon, 15 Mar 2021 at 10:53, Desmond @.***> wrote:

@vitacon https://github.com/vitacon, I have been distracted by other projects, I'm sorry to say, and I'm sure the code hasn't gotten any less stale in the last three years. I received an email awhile ago from someone (sorry if it was you) looking for ways to get it working with some standardized file formats and packaged in an .AppImage (I think, going on memory), but I lost the thread of our conversation somewhere in the shuffle.

My thoughts on this project are the following:

• It would be awesome to get it working again, there isn't, to my knowledge, a comparable alternative to the utilities the project maintained.
• I don't have any experience with XUL in general or XULRunner in particular
• I read somewhere that it might be possible to run XUL apps on Firefox 3 instead of XULRunner, which I believe was depreciated midway through Firefox 2. If this is possible, it would likely allow for the use of some slightly newer libraries, which might make the compilation process easier.
• I wonder whether it might be a better use of time to port the data structures and processes to another language, or at least another GUI toolkit. I'm particularly fond of Dart, and Flutter just went 2.0 with native compilation for all platforms, but that's an undertaking and a half, and would it even be the same project at the end? Debatably not.

I can take another look at the code tonight, I've got a bit of free time available, but yeah, I think the question is really, "Do we try to make obsolete code usable more than a decade after EOL, or do we treat it as a roadmap and algorithm design strategy for a re-imagining of the project from scratch?"

I'm preferential to the latter, but I'm not sure a project of that scope is feasible without a small team collaborating, preferably with more experience in the existing codebase than I have at present.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/n8willis/celtx/issues/1#issuecomment-799005042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARCEKYYW3XCKPGY6VO7C6DTDVEAXANCNFSM4CKTMN3Q .

[SecareLupus]

I don't have any experience packaging applications for official repos, but that's awesome that you got it building in debian. I'll take a look at your fork and see if there's any reason I shouldn't pull it and continue any work/research from there.

Does anyone know whether an XULRunner application can even be run securely, given the abandonment of its framework? Celtx doesn't access much untrusted internet data that would allow injection, but could a specially formulated save file run unsigned code? I'd like to help this exist again, in one form or another, but I dunno what that should look like.

[vitacon]

"re-imagining of the project from scratch"

I guess so. I believe all this mess could be replaced by some 500 kB of C# code...

[SecareLupus]

It is mostly just a front end to an iCal, some document formatting rules, and a database of entities. Everything beyond that is mostly ui sugar.

WRT this code though, I'm working on writing a docker file that can compile the current open-celtx codebase, but it's complaining something about lacking a make file for the composer editor. Once that is building it'll be way easier to identify which dependencies are necessary and which ones are superfluous.

C++ and makefiles are really not my strong suit, so I've got a ton of blind spots with this codebase, but if there's interest and activity I'll continue to help as I can.

[amworsley]

I don't know what your actually building. Your celtx code base or something else.

I got my branch to compile on debian stretch and applied some bug fixes to some seg faulting crashes. It can read in the celtx save files and run. If your trying to re-compile the original code based you would want to look at the changes I made.

As I said I don't know what you are compiling though.

Andrew

On Tue, 16 Mar 2021 at 01:33, Desmond @.***> wrote:

It is mostly just a front end to an iCal, some document formatting rules, and a database of entities. Everything beyond that is mostly ui sugar.

WRT this code though, I'm working on writing a docker file that can compile the current open-celtx codebase, but it's complaining something about lacking a make file for the composer editor. Once that is building it'll be way easier to identify which dependencies are necessary and which ones are superfluous.

C++ and makefiles are really not my strong suit, so I've got a ton of blind spots with this codebase, but if there's interest and activity I'll continue to help as I can.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/n8willis/celtx/issues/1#issuecomment-799468154, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARCEKZTVC6YA3LWZ4QJS23TDYLCLANCNFSM4CKTMN3Q .

[SecareLupus]

@amworsley, I merged your open-celtx:master branch into a new branch on my fork, and have been writing a dockerfile to compile that. I know you said you were compiling on stretch, but I think it looked like you merged buster changes back into master, so I've tried extending from both official debian:stretch and debian:buster, but hit the same error on both containers.

make[5]: Entering directory '/usr/src/myapp/objdir/editor' /usr/bin/perl /usr/src/myapp/mozilla/build/autoconf/make-makefile -t /usr/src/myapp/mozilla -d .. libeditor/Makefile make[5]: No rule to make target '/usr/src/myapp/mozilla/editor/composer/Makefile.in', needed by 'composer/Makefile'. Stop. make[5]: Waiting for unfinished jobs.... creating editor/libeditor/Makefile make[5]: Leaving directory '/usr/src/myapp/objdir/editor' make[4]: [/usr/src/myapp/mozilla/config/rules.mk:632: export_tier_gecko] Error 2 make[4]: Leaving directory '/usr/src/myapp/objdir' make[3]: [/usr/src/myapp/mozilla/config/rules.mk:650: tier_gecko] Error 2 make[3]: Leaving directory '/usr/src/myapp/objdir' make[2]: [/usr/src/myapp/mozilla/config/rules.mk:605: default] Error 2 make[2]: Leaving directory '/usr/src/myapp/objdir' make[1]: [client.mk:1113: build] Error 2 make[1]: Leaving directory '/usr/src/myapp/mozilla' make: *** [Makefile:14: all] Error 2 The command '/bin/sh -c make' returned a non-zero code: 2

Dockerfile attached at gist: https://gist.github.com/SecareLupus/cb899fd0ed6101b2b5273fd85b31b57b

I'm not sure why the build is failing, maybe I've missed a dependency for the composer editor, but I thought I covered all the needed dependencies (with a bunch extra to spare) I'll keep poking at it in the meantime, but if anyone's got any idea why the build is failing, I'm currently without strong leads.

[amworsley]

Thanks for the details, I'll look at it more later on today. I know there can be problems with autoconf files like *.in files with timestamps not being preserved by revision control systems. So on checkout the tools think a generated file is out of date and needs to be regenerated but the required files for this we're never saved in the repository... svn is terrible because it doesn't preserve file timestamps at all!

On Wed, 17 Mar 2021, 5:49 am Desmond, @.***> wrote:

@amworsley https://github.com/amworsley, I merged your open-celtx:master branch into a new branch on my fork, and have been writing a dockerfile to compile that. I know you said you were compiling on stretch, but I think it looked like you merged buster changes back into master, so I've tried extending from both official debian:stretch and debian:buster, but hit the same error on both containers.

make[5]: Entering directory '/usr/src/myapp/objdir/editor' /usr/bin/perl /usr/src/myapp/mozilla/build/autoconf/make-makefile -t /usr/src/myapp/mozilla -d .. libeditor/Makefile make[5]: No rule to make target '/usr/src/myapp/mozilla/editor/composer/Makefile.in', needed by 'composer/Makefile'. Stop. make[5]: Waiting for unfinished jobs.... creating editor/libeditor/Makefile make[5]: Leaving directory '/usr/src/myapp/objdir/editor' make[4]: [/usr/src/myapp/mozilla/config/rules.mk:632: export_tier_gecko] Error 2 make[4]: Leaving directory '/usr/src/myapp/objdir' make[3]: [/usr/src/myapp/mozilla/config/rules.mk:650: tier_gecko] Error 2 make[3]: Leaving directory '/usr/src/myapp/objdir' make[2]: [/usr/src/myapp/mozilla/config/rules.mk:605: default] Error 2 make[2]: Leaving directory '/usr/src/myapp/objdir' make[1]: [client.mk:1113: build] Error 2 make[1]: Leaving directory '/usr/src/myapp/mozilla' make: *** [Makefile:14: all] Error 2 The command '/bin/sh -c make' returned a non-zero code: 2

Dockerfile attached at gist: https://gist.github.com/SecareLupus/cb899fd0ed6101b2b5273fd85b31b57b

I'm not sure why the build is failing, maybe I've missed a dependency for the composer editor, but I thought I covered all the needed dependencies (with a bunch extra to spare) I'll keep poking at it in the meantime, but if anyone's got any idea why the build is failing, I'm currently without strong leads.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/n8willis/celtx/issues/1#issuecomment-800519231, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARCEK4W4OLBT4M76ZV3VG3TD6R5HANCNFSM4CKTMN3Q .

[SecareLupus]

I've continued poking at this, but haven't gotten any further. I've tried extending from debian:stretch, debian:buster, jokesterfr/xulrunner, and forwardcomputers/firefox-esr. It looks to me like the Makefile.in files are all pretty consistently constructed, so I'm not sure why one might be respected while another won't. I'm also not sure where to investigate your suggestion about timestamps, all the modified at dates seem to be consistent as well.

I think my next step is to try compiling in a stretch VM, and/or to clone your fork directly, in case it's something I screwed up in my merge (which was fast-forward-able, there weren't conflicts)

[amworsley]

Sorry Desmond, I just didn't do any work on this.

I've just tried to pull and build it on the buster (current debian stable) and it fails complaining about "...Package gtk+-2.0 was not found in the pkg-config search path. ..."

I've then switched to my laptop (with the orginal build) now running buster - it builds... I???

I 've done a clean git clone of the code and it compiles for me (under buster).

My guess is that there is some left over gtk+-2.0 config that allows it to work on the laptop but not on the server...

On Sun, 21 Mar 2021 at 09:23, Desmond @.***> wrote:

I've continued poking at this, but haven't gotten any further. I've tried extending from debian:stretch, debian:buster, jokesterfr/xulrunner, and forwardcomputers/firefox-esr. It looks to me like the Makefile.in files are all pretty consistently constructed, so I'm not sure why one might be respected while another won't. I'm also not sure where to investigate your suggestion about timestamps, all the modified at dates seem to be consistent as well.

I think my next step is to try compiling in a stretch VM, and/or to clone your fork directly, in case it's something I screwed up in my merge (which was fast-forward-able, there weren't conflicts)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Can you confirm exactly what your error message is?

is it the gtk+2.0 issue I have or another one?

Thanks

Andrew

[amworsley]

Hi Desmond, I found the missing libraries, at least under Buster, to get it compiling again.

libgtk2.0-dev libdbus-glib-1-dev libpangox-1.0-dev

I've make commit with an update to the README with the extra requirements listed.

On Sun, 21 Mar 2021 at 09:23, Desmond @.***> wrote:

I've continued poking at this, but haven't gotten any further. I've tried extending from debian:stretch, debian:buster, jokesterfr/xulrunner, and forwardcomputers/firefox-esr. It looks to me like the Makefile.in files are all pretty consistently constructed, so I'm not sure why one might be respected while another won't. I'm also not sure where to investigate your suggestion about timestamps, all the modified at dates seem to be consistent as well.

I think my next step is to try compiling in a stretch VM, and/or to clone your fork directly, in case it's something I screwed up in my merge (which was fast-forward-able, there weren't conflicts)

I suggest try compiling in a Buster VM.

Send me you error messages and perhaps I can see what's different with my environment. e.g. May be your missing yet another library or something.

Andrew

[SecareLupus]

Andrew, I can indeed compile under a buster vm, and have one setup to do so now.

Specifically using the image from https://www.linuxvmimages.com/images/debian-10/ if anyone else is following along. The build-dep for firefox-esr is "necessary" in that it doesn't compile without it, but the specific dependencies needed are probably much more limited, not that it's worth tracing down what the pared list would look like.

So cool, my issue is clearly docker-specific, and your code has it running on modern PCs, I probably don't need to worry about the dockerfile if we can now compile with a non-EOL'd distro. I've added the additional deps and it still fails at the same issue, so I'll put that idea on the back-burner as not needed for now.

So if this now can be confirmed to build in modern debian with the instructions provided in the Readme, do we want to close this particular ticket, and then further discussion on bug fixes/upgrades/redesign questions on separate tickets? probably on your fork instead of n8willis', since they've not been following along anyway? I dunno how much you're looking to participate in future work, whatever that might look like, dunno how long I'll be around myself before other projects (or a real job) demand attention.

RE: branding... do we know that the people who now own Celtx Studio won't bother us with the name open-celtx? They might not have a leg to stand on, but IANAL, so I was erring on the side of caution by rebranding to drood, which I felt was thematically related, and similarly punny. I am not attached to my branding wrt the actual project, but I am hoping you'd know better than I, since you started the re-re-branding :)

I think those are my main logistical questions now, I'm happy to move forward with this in any direction, but I'm not sure what a next step should be. I'm still fond of the idea of porting the features and concepts to Flutter, or perhaps something like Electron, (or even C#, but I don't know C#) but I know that's effectively rebuilding it from scratch. Do you (or anyone else for that matter) have plans or goals moving forward for this project or its spiritual progeny?

Desmond

[amworsley]

That's great news. I'm so glad to hear it from you.

The way forward as I see it you need some users to give it direction and need. I don't use it so I can't really help there. I think re-writing it in something more modern would be very helpful as the main reason that the Debian people are not interested in sponsoring it as a package is that it is full of very old un-maintained code.

To transition to a newer code base I think needs to be done in steps - so re-working one small piece at a time. Then you can use the existing code base to confirm it still works on older saved files. Perhaps add a new missing feature or automate or improve a clunky aspect to make it more practical to use.

As for re-branding I think worry about such issues once you have some users. The main reason that people might use it is because they have older projects or experience with the original open source celtx system I think hence the name open-celtx - at least till it becomes a problem becauses people are using it....

Andrew

On Tue, 23 Mar 2021 at 15:22, Desmond @.***> wrote:

Andrew, I can indeed compile under a buster vm, and have one setup to do so now.

Specifically using the image from https://www.linuxvmimages.com/images/debian-10/ if anyone else is following along. The build-dep for firefox-esr is "necessary" in that it doesn't compile without it, but the specific dependencies needed are probably much more limited, not that it's worth tracing down what the pared list would look like.

So cool, my issue is clearly docker-specific, and your code has it running on modern PCs, I probably don't need to worry about the dockerfile if we can now compile with a non-EOL'd distro. I've added the additional deps and it still fails at the same issue, so I'll put that idea on the back-burner as not needed for now.

So if this now can be confirmed to build in modern debian with the instructions provided in the Readme, do we want to close this particular ticket, and then further discussion on bug fixes/upgrades/redesign questions on separate tickets? probably on your fork instead of n8willis', since they've not been following along anyway? I dunno how much you're looking to participate in future work, whatever that might look like, dunno how long I'll be around myself before other projects (or a real job) demand attention.

RE: branding... do we know that the people who now own Celtx Studio won't bother us with the name open-celtx? They might not have a leg to stand on, but IANAL, so I was erring on the side of caution by rebranding to drood, which I felt was thematically related, and similarly punny. I am not attached to my branding wrt the actual project, but I am hoping you'd know better than I, since you started the re-re-branding :)

I think those are my main logistical questions now, I'm happy to move forward with this in any direction, but I'm not sure what a next step should be. I'm still fond of the idea of porting the features and concepts to Flutter, or perhaps something like Electron, (or even C#, but I don't know C#) but I know that's effectively rebuilding it from scratch. Do you (or anyone else for that matter) have plans or goals moving forward for this project or its spiritual progeny?

Desmond

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[SecareLupus]

I don't have any strong binding to this project myself, beyond thinking it'd be a great thing to continue existing. I don't know that I have any significant claim to the project. I don't have any personal or professional use for script writing software since more than a decade ago.

I am happy to continue working on this project or a spiritual successor, even willing to help project manage and play maintainer as much as time allows, but I either need to find some volunteers who want to grind on such a project with me, or enough interested parties to make it worth spending a bunch of time solo grinding.

I totally get if you're not able to put in any more work, Andrew, but if anyone else has time, energy, expertise, or funding they wanted to throw at this idea, I am happy to help organize and work on such a project. Feel free to get in touch if anyone wants to help make this possible. Once I have an idea of what we have for available resources, then we can probably start to get an idea of what options are possible.

I will probably close this ticket at the end of April, to give people time to respond if they want to use this as a space to reach out RE: supporting the project, alternatively, open a ticket on my fork. I'll make another report before closing the ticket to let people know what the status is, and create a roadmap for people to take a look at, if interest allows.

Thanks everyone for the interest, the help, etc! Even if this is the end of the celtx desktop app, I'm glad we got it modernized enough to function again before EOL. Hopefully we can turn this project into something, but time will tell.

[vitacon]

FYI I decided to give it a try and I started from scratch. About 60 kB of "real code" so far. https://github.com/vitacon/Screenovator