With the ability to invoke a Render Node graph,
the development on branch `play` reached some kind of milestone
regarding the »Playback Vertical Slice«.
This is a good opportunity to update the reference platform
and upgrade the preview releases and packaging setup accordingly.
This will include adjustments to compile on recent compilers and
upgrade the build system to support Python-3.
- need to simplify the design to make it effective
- add small sharpening seams and balance with drop shaddow
- reorder the lightening/drakening bevels to work properly
on top of various background colours
rework each of the 32px, 48px and 16px variants
so that the shape appears clear and succinct when rendered,
taking the aliasing into account; fine-tune and balance shadows.
Since this is one of the most central concepts in Lumiera,
and this Icon is expected to become a hallmark of the Lumiera UI,
it seems adequate to spend about two days on this graphic work.
Create an Icon or Emblem to represent the Placement concept.
Alluding to an Anchor, a Hook and the Letter "P"
This expands upon an Idea conceived some years ago
and used thus far within architecture and design diagrams
- remove unreferred definitions
- remove redundant style settings
- place bounding box tiles uniformly
- establish a standard stacking order
- introduce a naming scheme for the IDs
The reason for this pedantry is to simplify maintennance,
and to make the actual changes stand out clearly in Git
the new structure causes them now to be installed into $TARGET/stage
which is simply not what I want. I still consider $TARGET/gui the better choice,
since an administrator or packager is not aware of our layer namings.
The existing solution was half baked anyway, it did not really replicate the source tree.
On the other hand, I want to retain the location of the CSS files within the GUI tree,
since I consider it a good practice, to keep "code-like" resources with the actual code,
and not far away in some arcane "data" directory.
No I've noticed, that the env.GuiResource() function is only used once, for this very task.
So, for the time being, we can keep it simple and deditaced to that task, i.e
we pick up all CSS files we find and install it into a single target directory.
NOTE: this issue has brought to my attention two further, completely unrelated issues
* Ticket #1192 (Lumiera hangs on failed GUI start)
* The ProcDispatcher does an idle wait, due to an error in timed-wait implementation
Even while we (still) have the goal to ship our own stylesheet and provide
the typical subdued media-aplication look, right now this porting and styling effort (#1023)
is unfinished and handled with rather low priority (writing code is more important
than toying with styles and looks).
This alternative stylesheet is meant to be used with a typical "light" desktop theme.
We'll add just the bare minimum of definitions to make lumiera work well in that setup.
And right now, I'll use that setup to continue with my development work
This is a development snaphot pre release of Lumiera.
It features codebase maintenance, upgrade to C++14 and GTK-3
and some work towards a Proc-GUI connection (unfinished)
Update README, AUTHORS, LICENSE and similar release docs.
...this will be the third preview release
Lumiera is still in pre-alpha stage, and thus
there are no proper releases, just preview snapshots.
Again this version will be built and packaged
on several supported Linux platforms
...this will be the second preview release
Lumiera is still in pre-alpha stage, and thus there
are no proper releases, just preview snapshots
from time to time.
But we're providing Debian packages allready
the 'missing path' test still works, but rather
accidentally: the plugin search path retrieved from
resolving $ORIGIN is an absolute path, while this
test uses relative paths; thus the querried plugin
won't be found. In the second test, we set an
environment override, using the relative path
(which is now 'modules'). Thus the discovery works.
connect config-facade with the new BasicSetup implementation
to fetch values from setup.ini, instead of the (not implemented)
Config-system. Hook this new lookup mechanism into the
plugin loader to retrieve the search path from there
- use custom builders
- clean up specification of target paths
- generated executable is fully relocatable
- read a bootstrap INI instead of compiled in searchpath
the installed lumiera exe can even be started...
...well with a bit of cheating: you need to cd into the lib/lumiera
because the PLUGINPATH problem isn't solved yet
