Design concept and conclusion

Too much design leads to nothing. Design is based on the need. More design dedication involved comes to the strength of the design,

A huge design comes from countless small designs.

Design period is shortened only if changes are made. True correctness won’t be achieved by one design, but by multiple renovation. The correctness of a design decides the greatness of a design.

For software, there is no absolute way. Success of software comes with no definite rule, but just methods that increases the chance of success. No successful method can be replicated to another application without any modification, with possible chance of success to the second application.

Some conclusion for software design.

Advertisements

Graphic view: line linking

For the graphic view, the interconnecting line between two items can now follows the object.

 

Next target is to multi-link the items.

A useful tool for windows

When writing complex code in windows, the most troublesome matter is to pack all DLL files into the folder before publish it. On the other hand, static build also causes a lot of issues, while multiple library inference (such as calling library that is dependent on another one) is hard to be totally linked static.

 

For example:

When I have a library that uses the QT DLL, I’ll call the library inside my main program. Even if QT is statically built, linking a library that is dependent to QT will causes additional DLL dependency, which is not easily solvable.

 

To pack the DLLs, the simplest method is to pack it by hand. There is a tool long time ago, but it might not function properly now (especially in win7/win8)

 

http://code.google.com/p/windows-executable-packer/

http://www.openrce.org/blog/view/735/DLLPackager_v1.0

 

 

When operating with the dependency walker for solving the problem above, several steps are convenient:

 

  1. Remove the PATH folder from Option->Configure Module Search Order by pressing the << mark at the opened UI dialog. This act can avoid ambiguous dll dependency due to the same binary at different PATH folder.
  2. Add necessary folder that is required by your development library or tool-set (such as QT bin or opencv bin).
  3. When the tree comes out, remove system32 folder (system default)
  4. Include remaining dll files should be sufficient to run your application.

Note: Using this method, it is important not to put the application required dlls into the system32 folder. Else, extracting the dll dependencies will be very-very difficult.

 

I have not yet understood the console usage. If console usage is fine, dll copy automation will be possible.

Connection / integration from the OS to your own graphical apps

Traditional coding is simple, you write the code, and execute it. To execute the file, a command shell is provided for that, and it is done.

 

For GUI, the simple concept is that a person write a piece of code, and execute it. What makes it complex is the callback/signal-slot/non-sequential coding methodology, which requires advanced C++ programming to conquer the UI solution.

 

However, it is not the end of the story. When the OS is to be interacting with the APP, things are a little bit more complex. And most out of it, “different OS” act differently.

 

For the windows, double click of a file indicating executing the binary in a different process, which means that you’ll get the second/third/fourth window. When the file is executed, (as long as I know from at least windows XP) the filename is sent to the process directly, which is simple.

 

For the mac, double click acts totally different. When the double click is activated, the request is sent directly to the “already opened” process, unless the app is executed from the command line with “open -na” option. Besides, the filename that you choose will be sent to the app by using the event. To access the filename, you need to create event reception personally to accomplish that.

 

Therefore, modifying the application for different OS requires multiple instantiation and different redirection approach.

 

To achieve single application for multiple filename sending request, the first priority is the ability to open many window for one application, and the second would be sending the filename from different process to the single process. For MAC, opening multiple window is enough for the single application request.

 

UI style is always a battle, and neither will win the war ~~ Unless another killer concept is proposed, and the traditional need is also taken into consideration.

Environment variable for mac

Traditionally, the environment variable (envVar) is considered the same as linux, but it is different now.

 

For mac, the activation of program is separated into shell command binary (console based) and GUI binary. Based on the way the binary is launched, the environment variables are now separated into two layer.

 

First layer is traditional .bash_profile or /etc/bashrc. Those variables will only affect the shell command binary, not the GUI ones.

 

To make environment variable visible to the GUI (non-console based app), the launchctl is involved

So, to test the environment variable or temporally use the variable, use

 

launchctl setenv var value

 

If those are to be stored and reused, the variable should be written into the /etc/launchd.conf, by using

 

setenv var value

 

as the entry.

 

Then, QT creator can see those variables now. That is very abstract though…………

 

Reference:

http://www.dowdandassociates.com/content/howto-set-an-environment-variable-in-mac-os-x-slash-etc-slash-launchd-dot-conf/

 

QT graphic view resize

QT graphic view resize

QT graphic view resize

OSX related information

Open APP inside command line:

open ***.app

 

QT automatic solving dynamic library (.dylib) tool (check help by issuing –help):

macdeployqt ***.app

Maya's Programming & Electronics Blog

An attempt at a proper programming & electronics blog