If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Lightworks made the clam that they were the first pro NLE video editor for linux, but thats not true at all, None of there ports of Lightworks come any where close to having the same feature set as oss offerings, for god sakes Kdenlive has 200+ Effects, and supports just about every video codec know to man. Lightworks is even crippling the oss code there using for video encoding and decoding and then offering that functionality as a feature in the pro version. Thats just dirty.
They also choose to go with Gtk instead of Qt? That doesn't make any since at all Qt and Python are they standard in anything VFX related. Even the Color Correction Software(DaVinci Resolve) and blackmagicdesign SDK's are all Qt. Nuke and NukeX, Maya, Mudbox, Motion Builder, Mari, Katana, Realflow, Houdini, Maxwell Studio, .... Are all Qt with Qt SDK's.
They also choose to go with Gtk instead of Qt? That doesn't make any since at all Qt and Python are they standard in anything VFX related. Even the Color Correction Software(DaVinci Resolve) and blackmagicdesign SDK's are all Qt. Nuke and NukeX, Maya, Mudbox, Motion Builder, Mari, Katana, Realflow, Houdini, Maxwell Studio, .... Are all Qt with Qt SDK's.
GTK is just their "Windowing level" layer, all they use it for is to create windows and receive input events.
The widgets and UI are entirely custom made.
GTK is just their "Windowing level" layer, all they use it for is to create windows and receive input events.
The widgets and UI are entirely custom made.
I understand that, but that's beside the point. There is no extra work that has to be done on there part in order to fall inline with every other application that is used
in professional studios, there making false clams in regards to them being a professional NLE, and there not even close to standard compliance.
AFAIK Lightworks doesn't support (OpenEXR, OpenFX, OpenColorIO, ...) without these Lightworks is going to be completely useless and be in the same position as
Gimp, Kdenlive etc.
With out OpenColorIO your going to edit in Lightworks and then send it down the pipeline and have to redo any color correction you may have made pre or post edit. Hence
why the above three are not only OSS but BSD/MIT, ... licensed because there mandatory!!!!, Adobe, Autodesk, The Foundry, .... Photoshop uses OpenColorIO and so Does Blender etc. They all do.
I understand that, but that's beside the point. There is no extra work that has to be done on there part in order to fall inline with every other application that is used
in professional studios, there making false clams in regards to them being a professional NLE, and there not even close to standard compliance.
Just saying, using Qt wouldn't change anything user visible at all.
Just saying, using Qt wouldn't change anything user visible at all.
Sure it would, if you wanted to write a plugin for Lightworks that could talk to Nuke or vise versa. Or any other professional VFX tool without wanting to tear your face off
because they all use Qt C++ and Python for there SDK's.
And there not just using the Gtk Toolkit for windowing that's bullshit, there's a mess of Glib and GObject code in Lightworks also.
I don't have to see there code, I know what its dependance?s are and I know what its linking to, on top of that I helped maintain Gtk for 8 years prior to v3.
Other than there own personal library's I know how the rest of it was put together. Core system functionality is using Glib, anything remotely object related is using GObject.
If there not using GObject for object related functions and instead mixing plane Gtk+ C and C++ there still going to be using GObject(See Below) but note that mixing
Gtk+ C and C++ is an extremely complex issue to have to deal with on your own, hence the development of Gtkmm and Xfce's C++ SDK.
Even if there entire interface is OpenGL based, other that the windowing system. There still using Gtk Widgets and Gobject to embed the OpenGL viewport.
Gtk Widgets, GDK, Glib, GObject are not mutually exclusive, if your using one then your using all of them to some degree.
I don't have to see there code, I know what its dependance’s are and I know what its linking to, on top of that I helped maintain Gtk for 8 years prior to v3.
I have no idea what you're talking about. Of course the app would link to GObject/GLib/GDK and the 6 or so other dependencies
of GTK because that's what they are: dependencies of GTK. I don't have to touch Pango, or gettext, to use GTK. Same with GObject.
Other than there own personal library's I know how the rest of it was put together. Core system functionality is using Glib, anything remotely object related is using GObject.
If there not using GObject for object related functions and instead mixing plane Gtk+ C and C++ there still going to be using GObject(See Below) but note that mixing
Gtk+ C and C++ is an extremely complex issue to have to deal with on your own, hence the development of Gtkmm and Xfce's C++ SDK.
Even if there entire interface is OpenGL based, other that the windowing system. There still using Gtk Widgets and Gobject to embed the OpenGL viewport.
Gtk Widgets, GDK, Glib, GObject are not mutually exclusive, if your using one then your using all of them to some degree.
Why the hell would they use GObject? I just told you they aren't even using Gtk widgets, there is no need whatsoever to extend Gtk.
You're just throwing around baseless claims without any backup.
Comment