Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Kelvin Glaß
    @m273d15
    Stand-up (18.11.2019):
    • I created a first GitHub Action that releases nightly builds of an IntelliJ build without IDE restrictions (installable in all JetBrains IDEs as e.g. PyCharm, CLion).
      The idea was to provide a solution for the question in saros-project/saros#740 and @drakulix asked whether a PyCharm version is available for educational purposes.
      See release.
    • Small documentation change
    • Open: A lot of infrastructure improvements (I will open issues), nightly releases in the real Saros project (not in my fork)
    • In Progress: The gradle PR saros-project/saros#721
    Stefan Moll
    @stefaus
    Tobias Bouschen
    @tobous
    Kelvin Glaß
    @m273d15
    Stand-up (21.11.2019):
    • I created the first GitHub Actions in order to run stf tests on pr/stf/* branches and publish nightly Saros/I releases.
    • I already prepared the GitHub Actions which will build and test the project as in travis, but also fixing #561 and with building against JDK11 as discussed in #750.
    Tobias Bouschen
    @tobous
    Stefan Moll
    @stefaus
    • Working on removal of Smack References outside of Core
      • saros-project/saros#766 to extend Contact Service to manage contact features
      • several others prepared
      • some stuff like SkypeManager needs more refactoring, some classes like XMPPConnectionService are not correct thread-safe, enough to do...
      • regarding ui dialogs in core code, now planning that the dialog handler is implemented by the (ui) caller as a function and passed
    Kelvin Glaß
    @m273d15
    Stand-up (25.11.2019):
    • NOP
    Tobias Bouschen
    @tobous
    Stefan Moll
    @stefaus
    • Some Reviews
    Kelvin Glaß
    @m273d15
    Stand-up (28.11.2019):
    • Some Reviews
    Stefan Moll
    @stefaus
    Kelvin Glaß
    @m273d15
    Stand-up (02.12.2019):
    • Review
    • Discussed that we need a separation of core and IDE agnostic logic
    Tobias Bouschen
    @tobous
    Tobias Bouschen
    @tobous

    We further discussed how to deal with UI specific logic that is shared between Saros implementations. As an option to avoid code duplication, we are considering creating a UI abstraction (in the core or as another module). This discussion also partly took place in saros-project/saros#776.

    But, as not all members of the core team were present, we decided to move the discussion to a VoIP session at a (yet undetermined) later date.

    Kelvin Glaß
    @m273d15
    Skype Meeting (11.12.2019), Topic: Separation of Core and IDE-independent UI logic:
    The general approach (summarized very briefly)
    • (Explanation what I mean with UI logic in the following:) UI logic that should be in the core is logic that has to be implemented in all plug-ins (as e.g. the interpretation of error codes). This logic uses an abstraction of UI components (e.g. the call of an UI notification handler).
    • We want to separate this logic from the basic core logic by introducing something like a core.ui package
    • As a general approach of creating useful interfaces in the core (for the plug-ins that consume the core),
      we would like to introduce small interfaces as soon as they are required (instead of creating a general purpose interface).
      As soon as we see that two interfaces are serving the same purpose, we will merge these interfaces (or introduce another abstract that serves the same purpose).