ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/common/display-interface-proxy.cpp

85 lines
2.4 KiB
C++
Raw Normal View History

refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
/*
Display(Proxy) - service providing access to a display for outputting frames
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2009, Hermann Vosseler <Ichthyostega@web.de>
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
Reorganise translation units for interface proxies from now on, we'll have dedicated individual translation units (*cpp) for each distinct interface proxy. All of these will include the interfaceproxy.hpp, which now holds the boilerplate part of the code and *must not be included* in anything else than interfac proxy translation units. The reason is, we now *definie* (with external linkage) implementations of the facade::Link ctor and dtor for each distinct type of interface proxy. This allows to decouple the proxy definition code from the service implementation code (which is crucial for plug-ins like the GUI)
2018-04-03 03:14:55 +02:00
/** @file display-interface-proxy.cpp
** Interface-Proxy for the lumiera::Display facade (experimental/deprecated).
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
** The purpose is to define a proxy implementation of lumiera::Display, in order to
** redirect any calls through the associated C Language Interface "lumieraorg_Display"
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
**
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
** @see display-facade.hpp
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
** @see display-service.hpp actual implementation within the GUI
Reorganise translation units for interface proxies from now on, we'll have dedicated individual translation units (*cpp) for each distinct interface proxy. All of these will include the interfaceproxy.hpp, which now holds the boilerplate part of the code and *must not be included* in anything else than interfac proxy translation units. The reason is, we now *definie* (with external linkage) implementations of the facade::Link ctor and dtor for each distinct type of interface proxy. This allows to decouple the proxy definition code from the service implementation code (which is crucial for plug-ins like the GUI)
2018-04-03 03:14:55 +02:00
** @deprecated obsolete early design draft from 2009;
Rework Interface-Proxy definition to fit with the new scheme everything works now after the switch. BUT this solution is ugly, we need to trigger template instantiation explicitly
2018-04-03 04:58:22 +02:00
** as of 2018 only kept in source to compile some likewise obsolete UI widgets.
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
*/
#include "include/display-facade.h"
Doxygen: fill in file level headlines for further application core services
2016-11-04 22:29:24 +01:00
#include "include/interfaceproxy.hpp"
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
namespace lumiera {
/// emit the vtable here into this translation unit within liblumieracommon.so...
Display::~Display() { }
Rework Interface-Proxy definition to fit with the new scheme everything works now after the switch. BUT this solution is ugly, we need to trigger template instantiation explicitly
2018-04-03 04:58:22 +02:00
/** static storage for the facade access front-end */
lib::Depend<Display> Display::facade;
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
} // namespace lumiera
namespace lumiera {
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
namespace facade {
refactor interfaceproxy.cpp to rather include the definitions this allows to put the proxy definitions alongside with the actually implementing service, which makes much more sense than having all in one huge interfaceproxy.cpp file
2009-02-09 01:21:01 +01:00
Improve the code for proxy generation more of a layout improvement, to avoid any code duplication. The mechanics remain the same - write an explicit specialisation - trigger template intantiation within a dedicated translation unit
2018-04-03 07:45:13 +02:00
Global-Layer-Renaming: adjust namespace qualification
2018-11-15 23:59:23 +01:00
/* ==================== stage::Display ====================================== */
Improve the code for proxy generation more of a layout improvement, to avoid any code duplication. The mechanics remain the same - write an explicit specialisation - trigger template intantiation within a dedicated translation unit
2018-04-03 07:45:13 +02:00
using Interface = LUMIERA_INTERFACE_INAME(lumieraorg_Display, 0);
using Facade = lumiera::Display;
using IHandle = InstanceHandle<Interface, Facade>;
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
template<>
Rework Interface-Proxy definition to fit with the new scheme everything works now after the switch. BUT this solution is ugly, we need to trigger template instantiation explicitly
2018-04-03 04:58:22 +02:00
class Proxy<IHandle>
: public Binding<IHandle>
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
{
//----Proxy-Implementation-of-lumiera::Display--------
Display::Sink
copy-n-paste-programming to define SessionCommand interface / service ...the sheer amount of mechanical replacements scattered all over these files might be a vivid indication, that the design of the interface system is subobptimal ;-)
2016-12-12 03:09:08 +01:00
getHandle (LumieraDisplaySlot display) override
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
{
_i_.allocate (display);
Sink sinkHandle;
sinkHandle.activate (display, _i_.release);
if (lumiera_error_peek() || !sinkHandle)
throw lumiera::error::State("failed to allocate output DisplayerSlot",
lumiera_error());
return sinkHandle;
}
public:
Improve the code for proxy generation more of a layout improvement, to avoid any code duplication. The mechanics remain the same - write an explicit specialisation - trigger template intantiation within a dedicated translation unit
2018-04-03 07:45:13 +02:00
using Binding<IHandle>::Binding;
style-adjustment: GUI indentation, naming and braces over time, a specific Lumiera code writing style has emerged. The GUI, as it stood, used somewhat different conventions, which now have been aligned to the common standard. Basically we use GNU style, with some adjustments for OO-programming, we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
2015-05-29 04:44:58 +02:00
};
Improve the code for proxy generation more of a layout improvement, to avoid any code duplication. The mechanics remain the same - write an explicit specialisation - trigger template intantiation within a dedicated translation unit
2018-04-03 07:45:13 +02:00
/** emit proxy code here... */
template
class Link<Interface,Facade>;
}} //namespace facade::lumiera
Reference in a new issue Copy permalink