BlackBox 2016. Development strategy.

The open discussion of hosting, forum, web-sites, community organisation and open voting

BlackBox 2016. Development strategy.

Postby Romiras » Mon Dec 28, 2015 10:04 pm

As known, there are growing number of BlackBox distributions derived from last release made by Oberon microsystems at October 2013: Center (community-driven), CPC (Helmut Zinn and others), OberonCore, Red (Ivan Denisov and others), BlackBox-SDL (Ivan Kuzmitsky and others).

Typical user of BlackBox may not notice about all the changes made under the hood. From the first sight everything may look the same...
Superficially difference will be minor for most users, IMO.

For me, only last one, BlackBox-SDL, has really unique features being working on top of OpenGL. See https://youtu.be/NEoHAy1e9NA and https://youtu.be/2KCBgkcFjlU for details.

Typical user may want these features in future releases:
  • built on native GUI toolkit for most common OSes: MacOS, GNU/Linux, Windows - not using emulation software layers like Wine.
  • better UI: menus organization, customizable toolbars for common operations, window positioning/switching tabs (stems from migration to good GUI toolkit).
  • embedded advanced editor with syntax highlighting.
  • code navigation through modules and names of procedures.
  • integration with Version Control Systems such as Mercurial, Git etc (show differences of lines in custom colors in side of editor). See history of changes for every file. Compare different revisions.
  • code analyzer as adviser when compiling & debugging code.
  • good library for general programmer facilities such as lists, hashes, queues etc (not tightly coupled with BB though).
  • probably most debatable point: separate typesetting capability, all development tools from the BlackBox framework, leave only essential part for running GUI and non-GUI components. Keep development IDE as separate components on top of core framework.

Apart of this, I imagine about running object code on top of mobile platforms in modern environments (via hardware/software renderers), such as Tizen, Android (commonly on Java VM) and Raspberry Pi on devices such as TVs, bankomats, kiosks etc. This is another level of progress.
Yet I think abstraction level in current code become obsolete. Everything in abstraction around GUI toolkit requires switching of mind to next level of abstraction (Ports, Fonts, Windows etc).
Last edited by Romiras on Wed Dec 30, 2015 9:37 pm, edited 1 time in total.
Romiras
 
Posts: 35
Joined: Tue Sep 17, 2013 5:55 am
Location: Tel-Aviv

Re: BlackBox 2016. Development strategy.

Postby Josef Templ » Wed Dec 30, 2015 5:16 pm

The current Center activities are focused around consolidating the changes of the various distributions
into the center's upcoming 1.7 distribution. The changes proposed in the CPC distribution are the main
source of our current activities. We try to integrate them in a way that preserves compatibility with 1.6 to the
highest possible degree and we make changes only if unavoidable. We refrain from integrating
experimental extensions and from changing anything because of personal preferences.
With only a handful of open issues left, a release can be expected in Q2 2016.
The feature we are currently working on is to prepare BlackBox for multiple languages, i.e. to provide
for localizable menus, documentation, and dialogs.

SDL was not a topic so far but could of course be considered in the future.
I don't know much about it. There is certainly room for improvements in the center's distribution
but it tries to maintain a high degree of stability and compatibility and thus it must be more conservative
than other distributions may afford to be.

- Josef
Josef Templ
 
Posts: 226
Joined: Tue Sep 17, 2013 6:50 am

Re: BlackBox 2016. Development strategy.

Postby Romiras » Thu Dec 31, 2015 11:07 am

Josef Templ wrote:There is certainly room for improvements in the center's distribution
but it tries to maintain a high degree of stability and compatibility and thus it must be more conservative
than other distributions may afford to be.
I understand then need to have stable distribution.
Anyway, do you think Center can adopt some of requested features for next releases?
Romiras
 
Posts: 35
Joined: Tue Sep 17, 2013 5:55 am
Location: Tel-Aviv

Re: BlackBox 2016. Development strategy.

Postby Ivan Denisov » Fri Jan 01, 2016 7:21 am

Romiras wrote:built on native GUI toolkit for most common OSes: MacOS, GNU/Linux, Windows - not using emulation software layers like Wine.

This work is suspended until stable release for windows.
Romiras wrote:better UI: menus organization, customizable toolbars for common operations, window positioning/switching tabs (stems from migration to good GUI toolkit).
This is optional and should be continued as components.

Romiras wrote:embedded advanced editor with syntax highlighting.
Сontradict the idea of Oberon syntax and available as component.

Romiras wrote:code navigation through modules and names of procedures.
Already available as component.

Romiras wrote:integration with Version Control Systems such as Mercurial, Git etc (show differences of lines in custom colors in side of editor). See history of changes for every file. Compare different revisions.
Already done for Git with odcread.

Romiras wrote:code analyzer as adviser when compiling & debugging code.
Need details.

Romiras wrote:good library for general programmer facilities such as lists, hashes, queues etc (not tightly coupled with BB though).
Few libraries exist, so if there will be some project which will require one, it can be done by someone.

Romiras wrote:probably most debatable point: separate typesetting capability, all development tools from the BlackBox framework, leave only essential part for running GUI and non-GUI components. Keep development IDE as separate components on top of core framework.
This is possible, but if it will sole any problem. No nobody needs this changes in distribution strategy, because the distributive is small size. Also nobody need this extra complexity for user for installing components. This should be made by the developer before distribution process.

Romiras wrote:Apart of this, I imagine about running object code on top of mobile platforms in modern environments (via hardware/software renderers), such as Tizen, Android (commonly on Java VM) and Raspberry Pi on devices such as TVs, bankomats, kiosks etc. This is another level of progress.
Now the aim is to keep IDE actual for Windows platform. That is already not such easy task. For embedded software is better to make some extra components and cross compilers as O7 by Alexander Shiryaev.
User avatar
Ivan Denisov
 
Posts: 263
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: BlackBox 2016. Development strategy.

Postby Romiras » Fri Jan 01, 2016 1:30 pm

Ivan Denisov wrote:
Romiras wrote:better UI: menus organization, customizable toolbars for common operations, window positioning/switching tabs (stems from migration to good GUI toolkit).
This is optional and should be continued as components.
Ivan Denisov wrote:
Romiras wrote:code navigation through modules and names of procedures.
Already available as component.
I believe these are basic features which can improve user experience thus should not be optional.

Ivan Denisov wrote:
Romiras wrote:embedded advanced editor with syntax highlighting.
Сontradict the idea of Oberon syntax and available as component.
What is "idea of Oberon syntax" and why it contradicts to automatic syntax highlighting?

Ivan Denisov wrote:
Romiras wrote:integration with Version Control Systems such as Mercurial, Git etc (show differences of lines in custom colors in side of editor). See history of changes for every file. Compare different revisions.
Already done for Git with odcread.
odcread is tool written in C++ and has no relation to integration with VCS into BlackBox. The framework should be able to assist in visual comparison and viewing history of changes without any external tools if there are no strong reasons to use them.

Ivan Denisov wrote:
Romiras wrote:code analyzer as adviser when compiling & debugging code.
Need details.
A goal is to provide facilities for writing better code, turned on by default on each compilation.

Ivan Denisov wrote:
Romiras wrote:good library for general programmer facilities such as lists, hashes, queues etc (not tightly coupled with BB though).
Few libraries exist, so if there will be some project which will require one, it can be done by someone.
A goal is to provide common facilities without reinventing the wheel by programmer. All essential facilities with common data structures can boost a development and eliminates the need to search them on internet.

Ivan Denisov wrote:
Romiras wrote:probably most debatable point: separate typesetting capability, all development tools from the BlackBox framework, leave only essential part for running GUI and non-GUI components. Keep development IDE as separate components on top of core framework.
This is possible, but if it will sole any problem. No nobody needs this changes in distribution strategy, because the distributive is small size. Also nobody need this extra complexity for user for installing components. This should be made by the developer before distribution process.
A goal is to split BlackBox into two parts: core framework and everything running on top of it, like developer tools/IDE. So core framework can be distributed, for example, via network, in even smaller size.
Romiras
 
Posts: 35
Joined: Tue Sep 17, 2013 5:55 am
Location: Tel-Aviv

Re: BlackBox 2016. Development strategy.

Postby Josef Templ » Mon Jan 04, 2016 10:50 am

I could imagine to include hierarchical menus in 1.7 but need to look at its implementation
in one of the CPC packages first, i.e. if it is well done and ready for prime time.
Hierarchical menus have been omitted in the original BlackBox for unknown reasons. May be
they are/were not supported on MacOS or some similar reason.
I find them quite useful and they can help to keep the menus short and well organized
at the expense of an indirection when activating a nested item.
This trade-off should be left to the application developer and should not be restricted by
the development system.

I also have a private extension of the properties dialog that speeds up the development
of GUIs enormously. It adds buttons that open the source code of the referenced link,
guard or notifier.

- Josef
Josef Templ
 
Posts: 226
Joined: Tue Sep 17, 2013 6:50 am

Re: BlackBox 2016. Development strategy.

Postby Robert » Tue Jan 05, 2016 10:05 pm

Josef Templ wrote:I could imagine to include hierarchical menus in 1.7 but need to look at its implementation
in one of the CPC packages first, i.e. if it is well done and ready for prime time. - Josef

I use the Module CpcDropDown, dated January 2004, by Juan Antonio Ortega. It has always worked well for me.
It only supports 1 level of sub-menu, but that is probably plenty!.
Robert
User avatar
Robert
 
Posts: 130
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: BlackBox 2016. Development strategy.

Postby martin_vahi » Wed Jul 27, 2016 3:32 am

As of 2016_07_27 I haven't written a single line of Component Pascal in my whole life. I just downloaded the BlackBox, executed it with wine on openSUSE Linux, read some introductory parts of the tutorial, surfed around at different Pascal and Oberon related pages to make sense of the Pascal-and-alike eco-system. That is to say, on this forum here I have the benefit of seeing the whole BlackBox and Component Pascal story with fresh sight. The goal of my current comment is to give some feedback.

It seems to me that the whole set of the Oberon/Pascal/A2 software projects seems to be a typical academic mess that is not at all specific to the institution called "ETH Zurich". I have seen similar mess in both, the University of Tartu and the Tallinn University of Technology. By mess I mean the fact that web pages are broken, project web pages, for example,

http://www.oberon.ethz.ch/

are not maintained. At best there are some corners that seems to be more maintained, like the

blackboxframework.org
projectoberon.com
freepascal.org
http://mseide-msegui.sourceforge.net/
lazarus-ide.org
pilotlogic.com (the open source Pascal IDE and library named CodeTyphon)

Unlike the Free Pascal echosystem, the "new Oberon", Component Pascal, seems to suffer heavily from the inability of its developers, including the highly honored academics, including the Niklaus Wirth, to notice that

TOTALLY INDEPENDENT OF THE PROGRAMMING LANGUAGE
there exists the issue of DOMAIN SPECIFIC DATA ENTRY.

For example, it takes some work to enter the rules for doing matrix multiplication, text searching, reading text in from different encodings, describing physics for game engines, etc. In practice the nice rules from university level study books are not good enough, because they have to be transformed to make them more efficient to execute on real hardware, but that's just optimization. Optimization is a lot of work, but I say that even without any optimization it's a lot of work to describe all those rules in any general programming language. That explains, why the old, archaic, Fortran numeric libraries are still in use in 2016: it takes a lot of domain specific knowledge and a lot of work to describe the domain specific rules. The result is that for historic reasons the best domain experts tend to prefer different programming languages and if a freelancer like me, who works on real-life-problems, wants to create a program from software components that best reflect the domain specific knowledge, the freelancer (or corporate developer) has to use multiple programming languages in the same application.

If my software were to use multiple programming languages, then the inter-operability of the programming languages is very important. As of 2016_07 the only connecting layer between different programming languages that I'm aware of, is the operating system. The Java Virtual Machine, .NET CLR, etc. do not really allow different programming language implementations to exchange data without some operating system dependent hacks that use files, sockets, messages, etc. May be I'm mistaken, but the way I currently understand the BlackBox 2016_07 implementation is that the BlackBox requires Wine to run on Linux. Wine has pretty huge RAM requirements, effectively making the argument about low resource consumption of the BlackBox irrelevant. I do not like to run the slow Wine on the Raspberry Pi, despite the fact that small computers like the Raspberry Pi, including the

https://getchip.com/
http://pine64.com/

might be exactly the target hardware for BlackBox based solutions. That being said, I do think that the concepts of the Component Pascal are very attractive and all that hard work that Niklaus Wirth and his colleagues and students have done over the decades deserves not just credit, which is kind of useless, but PRACTICAL ADOPTION. I think that it should not be the case that the grand master, Niklaus Wirth, retires with the knowledge that he has failed

https://youtu.be/xLTUvFboveM?t=47m32s

However, unfortunately the typical attitude of university staff that "I have completed my academic project, papers have been published, research grant covers only research, not engineering" almost guarantees that the research results will not be adopted outside of the academia, because people outside of the academia do not have the time/money to get to know the research project deliverables in the level of detail that allows them to convert the halve-complete product, the research project deliverables, to a component that can be used in practice, not to mention the duplication of efforts in the form of re-learning everything that the academic researchers have already learned. (The various numeric calculation libraries are a fine illustration: usable through API by almost anyone, but really hard to implement properly. The same with symbolic calculation software, image processing software, various image/video/sound codecs.)


Another serious mismatch between academic researchers and industrial practitioners is that the experimental software of computer science researchers does not have to be able to work with data that originates from the past, is encoded by using legacy data formats. Industrial practitioners have to be able to work with real-life-data, which can be decades old, encoded in some really old and archaic data format. The programming languages that were in use during the era, when the data was created/logged/saved have a library for reading and writing the old data formats, but all newer programming languages are faced with the question, whether it is economically feasible to implement the libraries for reading and writing all of those legacy data formats. A workaround, where a semi-legacy programming language P1 is used for converting the data from format F1 to format F2 and then some other semi-legacy programming language is used for converting the data from format F2 to some more modern format F3, till the data is in new-enough-format to be read by the library of the new programming language, still involves the execution of multiple components that have all been written in different programming languages. In that case there exists a necessity for the software components to exchange data. As I described earlier, the only actually connecting layer that I'm aware of in 2016_07 is the operating system: files, pipes, messages, TCP-IP, shared RAM, etc. I find that a database engine like the SQLite is a nice connection point, because that eliminates the byte and bit endianness issues, specially, if the application runs on multiple machines. On the other hand, the computer science researchers save a lot of time, if they do not have to spend their time on thinking about the legacy data formats. Grants and glory is awarded for novel mathematical ideas, not backwards compatibility with legacy data formats, so the computer science researchers deliver, what was ordered from them. That is definitely one scheme, how the nice work of computer science researchers gets ignored by the "stupid and backwards" industry.


My recommendation for alleviating the situation is to use an idea from marketing: the greater the number of use cases, where a product can be used, the greater is the potential market of the product. In terms of developer mind share: to attract more developers, the open source software product must be useful in a greater variety of different kinds of software projects. To make a programming language useful in practice, libraries of other programming languages must be usable with as small amount of work as possible and data exchange between components that have been written in different programming languages must be implementable without "too much" development work.

Thank You for reading my comment.
I hope that I wasn't too harsh. After all, it took a lot of hard work and love to create the Component Pascal, BlackBox, etc. but in the same vein, it would be really sad, if all that hard work got wasted due to a weak strategy.
martin_vahi
 
Posts: 5
Joined: Wed Jul 27, 2016 12:45 am

Re: BlackBox 2016. Development strategy.

Postby Ivan Denisov » Wed Jul 27, 2016 9:06 am

"use cases" is good advice, we can prepare some thoughts about this.
User avatar
Ivan Denisov
 
Posts: 263
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia


Return to Brainstorming

Who is online

Users browsing this forum: No registered users and 1 guest

cron